METHOD FOR PROVIDING INCENTIVE TO PLAY GAMING DEVICES 
CONNECTED BY A NETWORK TO A HOST COMPUTER 
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1. Field of the Invention 

This invention relates generally to gaming devices interconnected by a computer 
network and more particularly to a method of providing incentive to play such gaming 
devices. 
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2. Description of the Related Art 

Networked gaming devices are known in the art. Interconnecting a plurality of 
gaming devices, such as slot machines, via a computer network to a central computer 



provides many advantages. Such advantages include compiling and auditing data related to 
the amount of coins received by the gaming devices as well as the amount paid to players of 
the devices. 

Such networked systems are also useful for tracking individual player usage of the 
15 gaming devices. In prior art player tracking systems, the player is issued a player 

identification card which has encoded thereon a player identification number that uniquely 
identifies the player. The individual gaming devices are fitted with a card reader, into which 
the player inserts the player tracking card prior to playing the associated gaming device. The 
card reader reads the player identification number off the card and informs a central 
20 computer connected thereto of the player's subsequent gaming activity. Such tracking 

permits monitoring individual player usage by associating certain of the audit date with the 
player identification numbers. This allows gaming establishments to target individual 
players with direct marketing techniques according to an individual's usage or to provide 
bonuses based on amounts played by an individual player. 
25 Another advantage of operating networked machines relates to implementation of 

bonuses, such as double jackpots, where selected machines pay out twice the normal jackpots 
during a bonus period. Another type of bonus which can be operated on a networked system 
is a progressive jackpot in which a fraction of each coin played on a group of selected 
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machines is allocated to a pool which is paid to one of the players of the selected machines 
upon the occurrence of a predetermined event. 

Another benefit provided by such networked systems is cashless play. In some 
systems, such as that disclosed in U.S. Patent No. 5,265,874 to Dickinson et al. for a cashless 
gaming apparatus and method, a player account in a central computer is associated with a 
selected player. The player utilizes a card linked to his or her account to access credit in the 
account via a card reader associated with the machine as described above. Insertion of the 
card into the card reader permits the player to apply credits to the machine to play the game. 

Providing prior art cashless play is advantageous in that it eliminates the need for the 
player to carry and insert coins or tokens into gaming machines. It has not been, however, 
utilized to provide promotional incentives to selected players to induce them to play the slot 
machines. In the past, promotional incentives were provided by issuing certificates which 
may be presented at the casino issuing the certificate for a predetermined amount of free 
coins or tokens in order to induce the person presenting the certificate to play the machines. 
In a variation on this promotional incentive, the certificate may provide that when the player 
buys a predetermined amount of tokens, the casino will provide a matching amount of tokens 
without charge, also to induce play on the slot machines. There is a problem with both of the 
foregoing types of incentives, namely the casino cannot be assured that the free coins or 
tokens or those provided to match the player's contribution will be used to play the slot 
machines. Rather, the player may simply pocket any coins provided and not play the 
machines, or may cash in any free or matching tokens provided and pocket the money 
without playing the machines. The casino cannot be assured that players who play the 
machines in response to receiving either free or matching amounts of coins or tokens will 
play all of the casino's contribution on the machines. 

It would be desireable for an operator of networked gaming devices to provide 
promotional incentives in which the players are provided with free credits or credits which 
match amounts played by the player that can only be used for gaming machine play and 
could not be cashed out by the player. 



In one aspect, the present invention comprises a method of providing incentive to 
play gaming devices connected by a network to a host computer. Each gaming device is 
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associated with a card reader. Players of the gaming devices are each issued a card. A player 
account accessible by the host computer is created for each player. The player's card is 
associated with the player's account, which has a predetermined credit applied thereto. 

In one aspect, the account is debited responsive to insertion of the card into one of the 
card readers and the machine associated with the card reader is credited with the amount 
debited from the account. 

In another aspect, the account is debited, the gaming device is credited, and the player 
is paid any jackpots which result from gaming device play utilizing credit from the player 
account. 

In still another aspect, credit is applied from the player account to the gaming device 
each time the player inserts a coin into the gaming device. 

The foregoing and other objects, features and advantages of the invention will 
become more readily apparent from the following detailed description of a preferred 
embodiment of the invention which proceeds with reference to the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is an illustration of a system for monitoring and configuring gaming devices 

according to the invention. 

FIG. 2 is a block diagram of an electronic module associated with each gaming 

device to permit monitoring and configuring thereof. 

FIG. 3 is a schematic diagram of a data communication node of the electronic module 

of FIG. 2. 

FIG. 4 is a schematic diagram of a discrete machine interface circuit of the electronic 
module of FIG. 2. 

FIG. 5 is a schematic diagram of a player tracking module of the electronic module of 

FIG. 2. 

FIG. 6 is a schematic diagram of a card reader circuit of the electronic module of FIG. 

2. 

FIG. 7A is an exploded view of a card reader according to the invention. 

FIG. 7B is a rear perspective view of the card reader of FIG. 7 A. 

FIG. 7C is a front perspective view of the card reader of FIG. 7A. 

FIG. 8 is a schematic diagram of a display circuit of the player tracking module of 



FIG. 2. 

FIG. 9 is a schematic diagram of a personality board of the electronic module of FIG. 

2. 

FIG. 10 is a schematic diagram of a triac driver circuit of the electronic module of 

FIG. 2. 

FIG. 11 is a schematic diagram of a relay driver circuit of the electronic module of 

FIG. 2. 

FIG. 12 is a block diagram of a communication board included in each floor 
controller of FIG. 1. 

FIG. 13 is a flow chart for the power-on procedure for the data communication node 
(DCN) of FIG. 2, which is implemented in firmware executed by the DCN controller. 

FIG. 14 is a flow chart for processing of the discrete gaming device inputs, of FIG. 

13. 

FIG. 15 is a flow chart for the step of incrementing meter counts associated with each 
gaming device of FIG. 14, which is implemented in firmware executed by the DCN 
controller. 

FIG. 16 is a flow chart for the step of processing the serial interface between the 
gaming device and the data communication node of FIG. 13, which is implemented in 
firmware executed by the DCN controller. 

FIG. 17 is a flow chart for the step of processing the network interface between the 
floor controller and the data communication node of FIG. 13, which is implemented in 
firmware executed by the DCN controller. 

FIG. 18 is a flow chart for the step of processing the network message of FIG. 17, 
which is implemented in firmware executed by the DCN controller. 

FIG. 19 is a flow chart for the step of processing the data communication node 
request of FIG. 18, which is implemented in firmware executed by the DCN controller. 

FIG. 20 is a flow chart for the step of FIG. 13 of processing the player tracking 
interface, which is implemented in firmware executed by the DCN controller. 

FIG. 21 is a flow chart for the step of processing a valid inserted card of FIG. 20, 
which is implemented in firmware executed by the DCN controller. 

FIG. 22 is a flow chart for the step of processing player tracking information of FIG. 
21, which is implemented in firmware executed by the DCN controller. 



FIG. 23 is a flow chart for the power-on procedure for the player tracking (PT) node 
of FIG. 2, which is implemented in firmware executed by the PT controller. 

FIG. 24 is a flow chart for the step of processing the DCN interface of FIG. 23, which 
is implemented in firmware executed by the PT controller. 

FIG. 25 is a flow chart for the step of processing the DCN message of FIG. 24, which 
is implemented in firmware executed by the PT controller. 

FIG. 26 is a flow chart for the step of processing the card reader bezel update of FIG. 
23, which is implemented in firmware executed by the PT controller. 

FIG. 27 is a flow chart for the step of processing the card reader of FIG. 23, which is 
implemented in firmware executed by the PT controller. 

FIG. 28 is a flow chart for the power-on floor controller process, which is 
implemented in software executed by the floor controller. 

FIG. 29 is a flow chart for the message processing step of FIG. 28, which is 
implemented in software executed by the floor controller. 

FIG. 30 is a flow chart for the message handling step of FIG. 29, which is 
implemented in software executed by the floor controller. 

FIG. 31 is a flow chart for the step of assigning unique machine addresses of FIG. 30, 
which is implemented in software executed by the floor controller. 

FIG. 32 is a flow chart for the system monitoring step of FIG. 28, which is 
implemented in software executed by the floor controller. 

FIG. 33 is a flow chart for the event handling step of FIG. 32, which is implemented 
in software executed by the floor controller. 

FIG. 34 is a flow chart for bonus control, which is implemented in software executed 
by the floor controller. 

■25 DETAILED DESCRIPTION 
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15 I. SYSTEM ORGANIZATION 

A. SYSTEM OVERVIEW 

A system for operating a plurality of gaming devices is shown generally at 10 in FIG. 
1. The system, hereinafter described, monitors and reconfigures a plurality of gaming 
devices or machines 12-16 and 22-26. The system includes the following capabilities: 

20 remote reconfiguration, accounting data extraction, integrated player tracking, and cashless 
play. Remote reconfiguration includes sending a reconfiguration command from a host 
computer to one or more of the gaining devices. The gaming devices, on receiving a 
reconfiguration command, will reconfigure its jackpot payout schedule in accordance with 
the reconfiguration command. 

25 This reconfiguration, in the preferred embodiment, comprises activating a bonus 

payout schedule. This bonus payout schedule is in addition to the normal pay table of the 
gaming device. The bonus payout schedule provides for additional bonus payouts in addition 
to the payouts specified by the device's normal pay table. The difference between the two is 
important for regulatory reasons. The composition of the pay table is subject to regulation by 

30 the various state gaming commissions while the bonus payout schedule is not. The preferred 
embodiment currently activates only the bonus payout schedule responsive to the 
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reconfiguration command, while not altering the payout table. The invention, however, is 
not limited to activating only the bonus payout schedule. Other embodiments, which would 
be subject to regulatory approval, could modify the device's payout table. The preferred 
embodiment, however, does not. 

The system, according to the invention, implements a variety of bonusing events 
through this reconfiguration process. These bonusing events include: a multiple jackpot 
wherein the gaming device reconfigures its payout to be a multiple of its default payout 
schedule; a bonus jackpot wherein the gaining device reconfigures its payout schedule to 
payout an additional bonus amount when certain conditions are met; and a progressive 
jackpot wherein two or more gaming devices are combined in a progressive jackpot having a 
progressive jackpot payout schedule. 

The system, according to the invention, also provides for integrated player tracking 
and accounting data extraction. Unlike prior art systems that use disparate systems for player 
tracking and accounting data extraction, the system 10 provides for player tracking and 
accounting data extraction over the same network. The player tracking, according to the 
invention, allows the casino to run certain promotional events. The integrated player 
tracking and accounting data extraction also allows the system to support cashless play 
wherein a credit is given to a player over the network. 

The system 10 includes one or more floor controllers 18 and 28. Each floor controller 
supports up to a predetermined maximum number of gaming devices. In the preferred 
embodiment, each floor controller can support up to 1024 gaming devices. The preferred 
embodiment also supports up to eight floor controllers. Thus, the system 10 can support up 
to 8192 separate gaming devices. 

The system supports a multiplicity of various gaming devices. The gaming devices 
12-16 and 22-26 shown in FIG. 1 are the type having a pull handle for initiating a game, e.g., 
slot machines. However, the invention is not limited to such gaming devices. The gaming 
devices shown in FIG. 1 can also be gaming tables or push button operated machines as well, 
e.g, video poker. As will be described hereinafter, the system supports any gaming device 
providing traditional discrete connections, e.g., coins-in, coins-out, etc., as well as those 
having serial interfaces, as described below. 

The floor controllers 18 and 28 are, in the preferred embodiment, IBM-compatible 
personal computers. Each floor controller is responsible for monitoring the activity level of 
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the corresponding gaming devices connected thereto and issuing commands to the associated 
gaming devices to reconfigure their payout schedules during certain bonusing events. The 
floor controllers issue status requests to each of the individual gaming devices to determine 
the activity level of each. In the event the floor controller detects any activity, the floor 
controller communicates that activity to a file server 32, which is connected to the floor 
controllers via a high speed network 38 connected therebetween. 

In the preferred embodiment, the file server 32 includes a high performance personal 
computer or work station having a large hard disk capacity in order to store the gaming 
device activity therein. In the preferred embodiment, the high speed network 38 is a ten 
megabyte ethernet network. The system 10 also includes commercially available network 
software to support the industry-standard ethernet network 38. An example of such network 
software is Novell network software sold by Novell of Provo, Utah. The file server 32 also 
includes a database program by which reports can be generated using the data stored on the 
file server. Such reports include, e.g. area, model, denomination and summary reports. The 
database software also allows a user to generate custom reports. The database software is 
based on the industry-standard Paradox database language. 

The system 10 also includes a pit terminal 34 which is also connected to the ethernet 
network 38. The pit terminal 34 is also a standard personal computer, in the preferred 
embodiment, and can be used to monitor the gaming device activity in the pit. This terminal 
34 can also be used as a security monitoring device to detect any unanticipated events like 
fills or payouts. 

The system 10 further includes any number of fill and jackpot processing terminals 
36. These terminals 36 are placed in the cage and/or the change booth areas of the casino for 
fill and hand-paid jackpot processing. When a fill is required, a floor person goes to the 
nearest cashier's booth and states the gaming device number requiring a fill. The booth 
attendant enters the number into the fill and jackpot processing terminal 36 located in the 
cashier's booth. The terminal 36 then looks up the record associated with the particular 
gaming device in the file server 32 to determine the correct fill amount. The terminal 36 also 
calculates a theoretical hopper balance for the particular device based on the latest meter 
information, as described further below. If the calculation shows a significant hopper 
balance, a warning is given on the computer screen from which security can then be alerted. 

A fill and jackpot processing terminal 36 prints a fill ticket upon demand. If the 
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calculated hopper balance was nearly zero, the terminal 36 cause the words "computer 
verified" to be printed on the ticket in place of a supervisor's signature. In the event that the 
calculated hopper balance was not near zero, an extra signature is required to complete the 
fill transaction. The system follows a similar procedure for processing hand-paid jackpots. 

A dispatch, station (not shown) can also be included in the system. The dispatch 
station allows the casino to monitor activity on the gaming devices and "run the casino" from 
one location. The dispatch station allows the dispatcher to monitor customer service, 
maintenance, and security events and direct other casino personnel to handle these situations 
appropriately. For example, during hopper empties (fills) and jackpot events, as indicated by 
the dispatcher station, the dispatcher could radio down to the floor to have someone verify 
the event. The dispatcher station can also indicate when a machine door is opened without a 
technician card inserted, for example, in which case the dispatcher could take the appropriate 
course of action. 

The above-described system 10 is but one embodiment of the system according to the 
invention. The system tasks can be allocated in a variety of ways amongst the system 
computers including floor controllers 18 and 28, file server 32, pit terminal 34 and fill and 
jackpot terminals 36. In some cases, the pit terminal 34 and fill and jackpot terminals 36 can 
even be eliminated and their tasks allocated to the floor controller or file server. In fact, 
because the file server 32 is essentially a virtual hard disk for the floor controllers 18 and 32, 
the floor controllers and the file server can be considered a single host computer for the 
system 10. 

B. DATA COMMUNICATION NODE 
1. Overview 

In order to communicate with the floor controller, each gaming device includes 
therein an electronic module 40, as shown in FIG. 2. This module 40 can be inserted into a 
variety of pre-existing gaming devices. The module allows the host computer to uniquely 
identify the gaming device on the network, including the device type. The module 40 
includes two main subcomponents: a data communication node 42 and a player tracking 
module 44. The data communication node 42 keeps track of the coins-in, coins-out, coins to 
drop, games played, jackpot occurrences and other related functions of the associated gaming 
device. The player tracking module 44 keeps track of the player that is playing the 



10 



associated gaming device. Together, the data communication node 42 and the player 
tracking module 44 allow the floor controller connected to the associated gaming device to 
monitor and control the activity of the gaming device. The system hereinafter described in 
detail includes the following capabilities: slot accounting, player tracking, bonus jackpots 
and cashless play. 



The data communication node (DCN) 42 includes a data communication node 
controller 46, which in the preferred embodiment is an HD6473258P10 controller 
manufactured by Hitachi of Tokyo, Japan. The DCN 42 is coupled to the player tracking 
controller 44 through bus interface logic 45, The bus interface logic 45 is conventional 
interface logic including, for example, transceivers, as is known in the art of digital design. 

A memory 48 is connected to the DCN controller 46. The memory includes program 
memory for storing program instructions for the DCN controller 46. In the preferred 
embodiment, this program memory includes a nonvolatile read-only memory (ROM). 
However, this program memory could also be flash or "battery" backed RAM in order for the 
program memory to be updated by the floor controller. In the event flash or "battery" back 
RAM is used the floor controller would download the updated program to the DCN 
controller and the DCN controller would overwrite the program memory with the 
downloaded program. 

The memory 48 also includes system memory, e.g., static random-access memory 
(SRAM) for storing the gaming device information. This gaming device information 
includes at least the following meters: coins-in, coins-out, coins to drop, games played, 
jackpot occurrences. A separate meter counter is kept in memory 48 for each of these values. 
To increase reliability of the data, in the preferred embodiment, a redundant set of these 
counters is kept in a physically separate memory device within memory 48. Moreover, the 
memory devices storing these counters are nonvolatile so that in the event of a power failure 
the counts will be retained. The nonvolatile memories can either be battery-backed SRAM 
or electrically erasable programmable read-only memory (EEPROM). Although memory 48 
is shown external to DCN controller 46, much if not all of the memory 48 can be included in 
the DCN controller 46. 



Controller and Memory 
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Network Interface 



The data communication node 42 also includes a network interface 49 for connecting 
the data communication node 42 to the associated floor controller. The network interface is 
coupled to the floor controller through a personality board 202, described below. 

A more detailed drawing of network interface 49 is shown in FIG. 3. In FIG. 3, the 
DCN controller 46 receives data from the floor controller over conductor 52 which is 
optically isolated from a connector 51 by optical isolator circuit 54. The DCN controller 46 
transmits data to the floor controller over conductor 56, which is optically isolated from the 
connector 51 by optical isolator circuit 58. Each of the opto-isolator circuits 54 and 58 
include an opto-coupler as are known in the art. A bus 222 (FIG. 2) is connected between the 
network interface 49 and the personality board 202. 



Referring to FIG. 2, the data communication node includes a serial machine interface 
60. The serial machine interface 60 allows the data communication node 42 to communicate 
with the associated gaining device advance serial interface as contrasted with the discrete 
interface, to be described further hereinafter. A bus 224 (FIG. 2) connects the serial 
machine interface 60 to the associated gaming device at connector 62. The serial interface, 
in the preferred embodiment, is a standard RS-232 three wire interface. 

Referring to FIG. 3, the DCN controller 46 receives data from the gaming device over 
conductor 64 which is connected between the DCN controller 46 and a differential to single- 
ended converter 66. The DCN controller 46 transmits data to the gaming device over 
conductor 68 connected between the DCN controller 46 and the converter 66. The converter 
66 converts the differential inputs of the serial interface 62 to a single-ended output which is 
transmitted over conductor 64 to the DCN controller 46. The converter 66 also converts the 
single-ended input received from the DCN controller 46 to a differential output signal and 
transmits that to the serial interface 62. The serial machine interface is the means by which 
the DCN controller communicates certain reconfiguration data, referred to as reconfiguration 
commands, to the machine. These reconfiguration commands cause the machines to activate 
a bonus payout table to allow the machine to append bonus payments to their standard 
jackpot payouts, as specified by their payout table, during certain bonus activities. 



Serial Machine Interface 
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5. Serial Display Interface 

The data communication node 42 further includes a serial display interface 70 
illustrated in more detail in FIG. 3, The serial display interface 70 includes logic coupled 
between the DCN controller 46 and an expansion connector 71 . The expansion connector 71 
allows the DCN controller 46 to communicate with an expansion device connected thereto. 

6. Discrete Machine Interface 

The data communication node 42 also includes a discrete machine interface 72, which 
is shown in detail in FIG. 4. The discrete machine interface 72 includes a plurality of opto- 
couplers 78 coupled between the discrete outputs from the gaming device or machine and 
the DCN controller 46. The discrete outputs of the machine are received at terminals 74A- 
74J of a connector 74 via a cable (not shown) connected between the machine and the 
connector 74. The discrete outputs are coupled to corresponding inputs 76A-76J via opto- 
couplers78. The discrete outputs from the machine include: an EXTRA signal, a POWER 
signal, a COIN IN signal, a COIN OUT signal, a COIN DROP signal, a JACKPOT signal, a 
HANDLE signal, a TILT signal, a SLOT DOOR signal, and a DROP DOOR signal. Each of 
these signals correspond to a known event in the machine. For example, when a coin is 
dropped in the machine a COIN IN signal appears on terminal 74C. This COIN IN signal is 
then transmitted to the DCN controller 46 on line 76C via the associated opto-coupler. 

All of the signal lines 76A-76J include a pullup resistor and a pulldown capacitor, 
which combined form an RC network on the associated line. The resistors are, in the 
preferred embodiment, in the form of a resistor pack 80 and the capacitors are individual 
discrete capacitors 82. Alternatively, the capacitors can be removed for high-speed signals. 

7. Machine Configuration Circuit 

The data communication node 42, as shown in FIGS. 2 and 3, further includes a 
machine configuration circuit 84. In the preferred embodiment, as shown in FIG. 3, the 
machine configuration circuit 84 includes a parallel to serial converter 86, which includes 
eight parallel inputs IN, a serial input SIN, a clock input CLK, a strobe input STB, and a 
serial output SOUT. The parallel inputs IN are connected to a personality board, as 
described hereinafter, to receive a unique machine configuration number therefrom, which 
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uniquely identifies the type of machine that the data communication node is connected to. In 
the preferred embodiment, the machine identification number is comprised of six bits. 
Therefore, the two remaining parallel inputs can be used to provide additional inputs, such as 
additional discrete machine inputs, to the DCN controller 46. 

5 The machine configuration number presented on the parallel inputs of the parallel to 

serial converter 86 is latched therein responsive to a strobe signal received at the strobe STB 
input. A strobe input is generated by the DCN controller 46 on conductor 90 which is 
coupled to the strobe STB input. The parallel data is clocked out of the converter 86 to the 
DCN controller 46 on conductor 88 and connected between the serial output SOUT of the 

10 converter 86 and an input of the DCN controller 46 responsive to a clock signal received on 
the clock input CLK of the converter 86. The clock signal is generated by the DCN 
controller 46 and is transmitted to the converter 86 via conductor 92 which is coupled 
. £ between an output of the DCN controller 46 and the clock input CLK of the converter 86. 

M The converter 86 also includes a serial input SIN for receiving serial input data. The 

W " 

v\i5 serial input SIN is coupled to an expansion terminal 94C of expansion connector 94. 

• as 

Conductors 90 and 92 are also coupled to the expansion terminal 94 to provide the clock and 
if! strobe signals thereto. The expansion terminal 94 therefore provides the means for the DCN 

Pi controller 46 to access additional serial information through the parallel to serial converter 

86. In the preferred embodiment, the parallel to serial converter 86 is part number 4021 
£20 manufactured by Toshiba Corporation of Tokyo, Japan. 

C. PLAYER TRACKING MODULE 
1. Overview 

Referring again to FIG. 2, the module 40 coupled to each of the gaming devices 
includes a player tracking module 44. The player tracking (FT) module 44 includes a player 
25 tracking controller 98, a card reader 100, a serial display driver 101, a display 102, and 

expansion interfaces 104 and 106. The player tracking controller 98 communicates with the 
data communication node controller 46 through bus interface logic 110. The DCN controller 
46 and PT controller 98 maintain a master-slave relationship, respectively. Therefore, all 
communication is initiated by the DCN controller 46. The bus interface logic is conventional 
30 logic and its design is well-known in the art of digital electronics. 

In the preferred embodiment, the player tracking module 44, with the exception of the 




card reader 100 and the display 102, resides on a single printed circuit board, while the data 
communication node 42 resides on a separate printed circuit board. The player tracking 
module 44 and the data communication node 42 are then connected by a cable 111 such as a 
ribbon cable. 

2. Serial Display Circuit 

A more detailed drawing of the player tracking module 44 is shown in FIG. 5. In 
FIG. 5, the serial display circuit 101 includes a transistor Ql and a resistor Rl connected to 
the base thereof. A conductor 1 12 is connected between the PT controller 98 and the resistor 
Rl to provide a drive signal to transistor QL The drive signal causes transistor Ql to 
conduct a current and thereby drive a display connected to the collector of Ql at a terminal 
1 14 of a connector 115. In the preferred embodiment, the terminal 1 14 is connectable to a 
small vacuum florescent display to provide serial display data thereto. 

3. Serial Expansion Ports 

The player tracking module 44 also includes two serial expansion ports 104 and 106. 
Each of the expansion ports 104 and 106 includes a differential to single-ended converter 1 16 
and 118, respectively. In the preferred embodiment, these converters 116 and 118 are part 
number LTC490 manufactured by Linear Technology Corporation of Milpitas, California. 
The PT controller 98 communicates with each converter via two single-ended, serial signal 
lines: an input signal line and an output signal line. The converters convert the single ended 
signals appearing on these lines to differential signals. The differential signals, however, can 
be used as single-ended signals as is known in the art. The first expansion port 104 interfaces 
the player tracking node 44 with a large vacuum florescent display 102 (FIG. 5) used to 
display player tracking messages, as described further below. The display is connected to the 
connecter 1 15, in the preferred embodiment, by a cable 103. The other expansion ports 106 
provides the player tracking module with future expansion capabilities to support additional 
features. 

4. Card Reader 

Referring now to FIGS. 6 and 7, the card reader 100 will now be described. FIG. 6 
shows the electrical schematic for the card reader while FIG. 7 shows the mechanical 
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drawing thereof. In FIG. 7A, an exploded view of the card reader is shown. The card reader 
includes a plastic bezel 116 having a card reader opening 118 formed therealong for 
receiving a card 120 therein. The bezel 116 includes guide rails 122 and 124 disposed at 
opposite, respective lateral ends of the opening 118. The guide rails 122 and 124 have stops 
126 and 128, respectively. The guide rails 122 and 124 guide the card 120 through the 
opening 1 18 until an end of the card 120 contacts stops 126 and 128. The card is shown fully 
inserted in FIGS. 7B and 7C with the end of the card 120 abutting the stops 126, 128. 

The card reader also includes a: printed circuit board 130 having a longitudinal 
opening to allow the guide rails 122 and 124 to be inserted therein in order to allow the 
printed circuit board 130 to be pushed up flush against a mounting plate 132 of the bezel 116, 
as shown in FIGS. 7B and 7C. Mounted on one side of the printed circuit board 130 is an 
array of photodiodes 134 and an array of photodetectors 136. The photodiodes 134 are 
mounted on the printed circuit board along one side of the opening in the printed circuit 
board, while the photodetectors 136 are mounted on the printed circuit board along an 
opposite side of the opening. The photodiodes and the photodetectors are vertically aligned 
in a one-to-one relationship, i.e., one phptodiode for each photodetector. In the preferred 
embodiment, the array of photodiodes includes eight individual diodes spaced equidistance 
along the opening in the printed circuit board 130. The photodiodes 134 are mounted along 
the opening in the printed circuit board 130 so as to align with separate rows of openings in 
the card 120, as described further below. The card reader also includes optional light masks 
138 and 140. The light mask 138 is associated with the array of photodiodes 134 and has a 
plurality of openings therein, each opening corresponding to an individual photodiode in the 
array 134. Similarly, light mask 140 is associated with the array of photodetectors 136 and 
also has one opening for each of the photodetectors. The light mask 138 is mounted on the 
printed circuit board 130 beneath the array of photodiodes 134 along the opening in the 
printed circuit board 130. The light mask 138 is aligned with the photodetectors 134 so that 
the openings in the light mask 138 are directly beneath a corresponding photodiode in the 
array. The light mask 138 minimizes the amount of light emitted by a photodiode that can be 
detected by a photodetector other than the corresponding photodetector. The light mask 140 
is mounted on top of the photodetector array 136 so that the openings therein align with the 
individual photodetectors. The light mask 140 further eliminates extraneous light from the 
photodiodes as well as extraneous ambient light. 
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Also mounted on the printed circuit board 130 are a plurality of light-emitting diodes 
142, as shown in FIG. 7C in broken line. The light-emitting diodes are mounted on a side of 
the printed circuit board opposite the side on which the photodiodes and photodetectors are 
mounted on. The light-emitting diodes 142 are mounted around the perimeter of the opening 
in the printed circuit board 130 and are received in a recessed portion 144 of the bezel 116. 
The light-emitting diodes 142 comprise a means for providing visual feedback to a user 
inserting a card 120 into the bezel 1 16, as described further below. In the preferred 
embodiment, the light-emitting diodes 142 are dual light-emitting diodes capable of 
producing two primary colors and a third combination color. 

Referring now to FIG. 6, an electrical schematic of the card reader is shown. The 
schematic includes the array of photodiodes 134 disposed along one side of the card reader 
opening 118 and the array of photodetectors 136 disposed along the opposite side of the 
opening 118. In the preferred embodiment, there are eight photodiodes and eight 
corresponding photodetectors. The photodiodes are arranged in pairs, with the two 
photodiodes within each pair being connected in a serial fashion. The anode of the first 
photodiode in the pair is coupled to the supply voltage through resistor, while the cathode of 
a second photodiode in the pair is connected to an output of a driver circuit 144. The driver 
circuit, in the preferred embodiment, includes two open collector inverters connected in 
parallel. A signal is provided to the driver circuit 144 by the PT controller 98 over a 
conductor 146. A signal on conductor 146 causes the driver circuit 144 to conduct current 
and thereby actuate the photodiodes 134 substantially simultaneously. 

The photodetectors 136 are comprised of a plurality of light-sensitive phototransistors 
PD1-PD8. The emitters of the phototransistors PD1-PD8 are all coupled to ground. The 
collectors of phototransistor PD1 and PD8 are connected together and to a conductor 148 by 
which the PT controller 98 senses light detected by either phototransistor PD1 or PD8. 
Phototransistors PD2 and PD7 are similarly connected with the collectors of each being 
connected to a conductor 150. The collectors of phototransistors PD3 and PD6 are also 
commonly connected to a conductor 152. The collectors of the center phototransistors PD4 
and PD5, however, are connected to separate conductors 156 and 154, respectively. Also 
connected to each of the conductors 148-156 is a corresponding pullup resistor. In the 
preferred embodiment, the pullup resistors are included in a resistor pack 158. Each of the 
conductors 148-156 are connected to a connector 170, which is coupled to the PT controller 
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98 as described below. 

Based on the above configuration of the phototransistors PD1 and PD8, only five 
conductors are required to sample all eight of the phototransistors. Without more 
information, however, the player tracking controller 98 would be unable to determine which 
of the two phototransistors commonly connected to a particular conductor, e.g., conductor 
148, detected light. For example, if either phototransistor PD1 or phototransistor PD8 detect 
light, the voltage level on conductor 148 will drop from a high voltage of approximately 5 
volts to a low voltage of approximately 0.7 volts. Without more information, the player 
tracking controller 98 would be unable to determine which of the two phototransistors, PDl 
or PD8, actually sensed the light. According to the invention, however, the card 120, as 
shown in FIG. 7A, includes a first slot 150 by which the PT controller 98 can determine 
which of the two photodetectors detected the light, as described below. 

The card 120 includes five rows of slots 152-160. The rows of slots 152-160 are 
arranged in a matrix with the corresponding slot locations within each of the rows being 
aligned in columns. Only the first slot 150 of row 152 cannot be aligned with any other slots, 
i.e., slot 150 is in a column all by itself. The individual slots within the rows of slots 152- 
160 encode unique player tracking information. Each slot represents a single binary bit in 
the player tracking information. Either one of two conventions can be used to encode the 
information. First, a slot can represent a binary 1 and no slot can represent a binary 0. 
Second, a slot can represent a binary 0 and no slot can represent a binary 1 . The player 
tracking information can include: a unique player identification number, the casino issuing 
the card, player membership information, etc. 

In the preferred embodiment, the card includes five rows of slots each having a 
maximum number of nine individual slots, thereby producing 45 possible slots. The first row 
of slots 152, however, is not used to encode player tracking information, but instead is used 
to synchronize the sampling of the player tracking information by the player tracking 
controller 98. Thus, only 36 slots are used to encode player tracking information in the 
preferred embodiment. This still allows 2 a36 possible combinations, which is more than 
adequate. 

The PT controller 98 uses the first row 152 to synchronize the sampling as follows. 
The PT controller 98 continuously samples the outputs of PD4 and PD5 looking for a slot. If 
a slot is detected on either PD4 and PD5 and no other slots are detected by any other 
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phototransistors the PT controller 98 determines that the detected slot must be slot 150. The 
PT controller 98 then continuously samples the output of the phototransistor that detected 
slot 150. Once a new slot is detected by that phototransistor, the PT controller 98 then 
samples the outputs of the other phototransistors, i.e., PD1-PD3 and PD6-PD8, on 
conductors 148, 150 and 152 for slots in of the other rows. Thus, the PT controller 98 
synchronizes the sampling of the other rows of slots to the detection of a slot in the first row 



It is important for the card reader to detect the orientation of the card in order to 
correctly interpret the player identification information encoded on the card. The card reader 
detects the orientation of the card 120 by detecting the slot 150. If slot 150 is detected by 
phototransistor PD4, then the card reader knows that the card is in the orientation shown in 
FIG. 7 A. In that case, the card reader knows that the player tracking information is actually 
being detected on phototransistors PD5-PD8, and can interpret the player tracking 
information accordingly. If, however, phototransistor PD5 detects slot 150, then the card 
reader knows that the card 120 is oriented 180 degrees from that shown in FIG. 7 A. In that 
case, the card reader knows that the player tracking information is being detected by 
phototransistors PD1-PD4, and can interpret the information accordingly. The PT controller 
98 can simply transpose the player tracking information sensed on conductors 148-152 
depending upon the detected orientation of the card. Thus, the card reader according to the 
invention is able to correctly interpret the player tracking information regardless of how the 
player inserts the card 120 into the bezel 1 16 of the card reader. The invention is able to 
accomplish this with only five conductors between the eight phototransistors PD1-PD8 and 
the PT controller 98. 

The card reader further includes a plurality of light-emitting diodes 142 that are 
mounted on the printed circuit board 130 and received in the recess 144 of the bezel 1 16, as 
shown in FIG. 7C. The LEDs 142 are mounted on the printed circuit board 130 so as to 
surround the card reader opening 1 18 as shown in FIG. 6. In the preferred embodiment, the 
card reader includes 24 dual diodes arranged in pairs. The dual diodes have two separate 
diodes, each being able to emit a different primary color of light. In the preferred 
embodiment, the dual diodes emit either red or green light. The dual diodes can also emit a 
third combination color if the two individual diodes in the dual diode are actuated 
simultaneously so that the two primary colors combine. In the preferred embodiment, this 
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combination color is approximately orange due to the differences in the intensities of the red 
and green light. 

The dual diodes are essentially treated as two individual diodes. The red diodes R in 
the dual diodes are driven by a driver circuit 162, while the green diodes G in the dual diodes 
are driven by another driver circuit 164. The driver circuits 162 and 164 are, in the preferred 
embodiment, two open collector drivers connected in parallel, as with driver 145. However, 
other equivalent driver circuits would be apparent to those skilled in the art. 

The dual diodes are arranged in pairs with the anodes of one of the dual diodes being 
coupled to the supply voltage +5 V and the cathodes of the other dual diode being connected 
to the output of the corresponding driver circuit. Accordingly, the red diodes are commonly 
driven by driver circuit 162, which is responsive to a signal received from the PT controller 
98 on conductor 166. Similarly, the green diodes are commonly driven by driver circuit 164, 
which is responsive to a signal received from the PT controller 98 on conductor 168. 
Therefore, the PT controller 98 can selectively actuate the red diodes, the green diodes or 
both by generating the corresponding signals on conductors 166 and 168. 

All of the conductors over which the PT controller communicates with the card 
reader, i.e., 146-156 and 166-168, are connected to a connector 170 as shown in FIGS. 6 and 
7A. The player tracking module 44 then includes a cable 172 that is connected between the 
connector 170 and the PT controller 98, as shown in FIG. 5. 

Although the preferred embodiment of the card reader is an optical card reader, the 
invention is not limited to such. The lighted bezel can be used in conjunction with any form 
of card reader such as a magnetic card reader, a bar code reader, etc. The method of 
providing visual feedback to the player herein described is a general method which can be 
used with a plurality of cards and card readers. 



Referring now to FIG. 8, a schematic for the display circuit 102 of the player tracking 
module 44 is shown. The circuit 102 includes a display controller 174, which in the 
preferred embodiment is a part number HD6473258P10 manufactured by Hitachi of Tokyo, 
Japan. Coupled to the display controller 174 is a memory 176 via bus 178. The memory 
176, in the preferred embodiment, is a 32KB SRAM. The memory 176 stores the variables 
and parameters necessary for the controller 174 to communicate with both the PT controller 
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98 and the display driver 186. The bus 178 includes the necessary address lines, data lines 
and control lines to interface in memory 176. 

In the preferred embodiment, the display 102 includes a vacuum fluorescent display 
(VFD) 184, which is organized as a 16 x 192 display matrix. Such displays are well-known 
in the art of digital electronics. The VFD 184 is driven by a driver circuit 186, which 
includes a plurality of individual drivers serially interconnected. In the preferred 



embodiment, these serial drivers are part number UCN5818EPF-1, manufactured by Allegro 
Microsystems, Inc. of Worcester, Massachusetts. The driver circuit 186 is connected to the 
VFD 184 by bus 188, which includes 160 individual conductors. The manner in which the 
160 bus lines are connected between the driver circuit 186 and the VFD 184 is known in the 
art, and is therefore not described in detail herein. 

The display controller 174 interfaces with the driver circuit 186 by a plurality of 
signal lines 190. These signal lines transmit the standard driver interface signals to the driver 
circuit 186. These signals include: a clock signal CLOCK, serial input data signal SDATA, 
a frame signal FRAME, a strobe signal STROBE, two output enable signals OE1/ and OE2/, 
a column clock signal COL CLOCK, and a column output enable signal COL OE/. These 
signals have well known functions in the display art and are therefor not discussed in detail. 
The signal names having a " / " represent active low signals while all other signals are active 
high. The display controller 174 generates these signals in the required sequence in order to 
serially clock the reformatted display data to the driver circuit. One of ordinary skill in the 
art could program the display controller 176 to generate these signals in order to display the 
desired message on the VFD 184 based on the foregoing description. 

The display 102 also includes a serial interface 192. The serial interface 192 is the 
means by which the PT controller 98 communicates a player tracking message to the display 
102. In the preferred embodiment, the serial interface 192 includes two opto-isolator 
circuits: one for the serial send data, the other for the serial transmission data. The display 
controller 174 is connected to the serial interface 192 over a two conductor serial bus 194, 
one conductor for receiving serial data from the serial interface 192, the other for 
transmitting serial data thereto. A connector 196 is also coupled to the serial interface 192. 
The connector 196 includes four terminals. Two of the connector terminals are dedicated to 
receiving serial input data and the other two terminals are dedicated to-transmitting serial 
data. A cable (not shown) couples the display 102 to the player tracking module 44 between 
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connectors 196 (FIG. 8) and connector 115 (FIG. 5). 
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Discrete Input Section 



The display 102 further includes a discrete input section 198. The discrete input 
section 198 is an interface between the discrete outputs of a gaming device and the display 
controller 174 much in the same way that the discrete machine interface 72 allows the data 
communication node to interface with a gaming device. Although in the preferred 
embodiment the discrete input section is unconnected to any discrete machine inputs, the 
discrete input section 198 allows the display 102 to operate as a stand-alone module for 
gaming devices in certain configurations. The discrete input section provides discrete input 
signals from an external device to the display controller 174 over a bus 200. The discrete 
input section 198 includes opto-isolator circuits such as part number TLP620 manufactured 
by Toshiba Corporation of Tokyo, Japan which provide single-ended input signals to the 
display controller 174. 

D. PERSONALITY BOARD 

Referring now to FIG. 9, a personality board 202 is shown in schematic form. The 
personality board 202 uniquely identifies the gaming device on the network. The personality 
board 202 indicates the type of gaming device, e.g., slot machine or video poker, including 
the manufacturer, and provides a unique machine identification number that the host 
computer can use to uniquely address the gaming device. The personality board 202 allows 
the devices to be readily removed and reinstalled in the network without any manual 
reconfiguration by the operator, such as resetting dip switches. 

The personality board 202 couples the data communication node 42 to a gaming 
device. The personality board 202 includes two connectors 204 and 206 and an identification 
circuit 208. The connector 204 couples to the data communication node 42, as described 
further below. The connector 206 connects to the particular gaming device. The components 
shown in FIG. 9 are mounted on a printed circuit board that is mounted inside a connector 
harness (not shown). The personality board allows the DCN to be easily removed and 
reinstalled from the network with minimal effort. 

The personality board uniquely identifies the machine by providing both a 
configuration number, which indicates the type of gaming device that is connected to the 
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connector 206 and a unique identification number, which is used by the system 10 to 
maintain records on the machine. The configuration number includes a six bit binary number 
which indicates the type of gaming device connected to the personality board 202. Each 
machine type is assigned a unique configuration number. This configuration number is 
encoded on lines CNFG0-CNFG5, which are connected to terminals 204Q-204V, 
respectively, of connector 204. Each line represents one bit of the binary configuration 
number. The individual lines are either tied to a supply voltage to represent a binary one or 
to ground to represent a binary zero. The six bit configuration number used in the preferred 
embodiment can encode up to 2 a6 different combinations and, therefore, different machine 
types. The configuration number for the embodiment shown in FIG. 9 is equal to 3CH. 

The configuration lines CNFG0-CNFG5 are coupled to the inputs of parallel to serial 
converter 86 (FIG. 3) through a connector (not shown). The terminals 204Q-204V of 
connector 204 have corresponding terminals 85Q-85V of connector 85, as indicated by 
corresponding lettered suffixes. This same lettering convention is used throughout. 

The configuration number is used by the DCN controller 46 as a means of 
interpreting the discrete input signals received from the machine through connector 206. 
Individual conductors coupled between connector 204 and 206 are labeled to correspond to 
the machine type having a configuration number 3CH. For a different machine type having a 
different configuration number, many of these conductors may have different functions. By 
providing a unique configuration number, the DCN controller can interpret the signals 
received on these lines accordingly. 

The personality board 202 also includes an identification circuit 208 which provides a 
unique machine identification number to the data communication node 42. The unique 
identification number is stored in a nonvolatile memory 210 and provided to a terminal 204N 
on conductor ID. In the preferred embodiment, the nonvolatile memory 210 is a part number 
DS2224 manufactured by Dallas Semiconductor of Dallas, Texas. In the preferred 
embodiment, the nonvolatile memory 210 includes a 32 bit ROM having a factory-lasered 
unique serial number stored therein. This serial number, i.e., the machine identification 
number, can be read out of the memory 210 by the DCN controller 46 to uniquely identify 
the machine connected thereto. The protocol for reading the identification number out of the 
memory 210, as is described in the data sheet for the part, is well known in the art. 

The identification circuit 208 includes a number of discrete components. The 
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memory 210 has a zener diode 212 coupled across the power and ground terminals of 213 
and 215 thereof. The identification circuit 202 also includes a first diode 214 coupled 
between the power terminal 213 and a data output terminal 217. The circuit 208 further 
includes a second diode 216 coupled between the data output terminal 217 and the ground 
terminals 215. A resistor 218 is interposed between the data output terminal 217 and the 

r 

connector terminal 204N. The terminal 204N is coupled to a corresponding terminal 74N of 
connector 74 (FIG. 4) by a bus 220 (FIG. 2). 

The discrete outputs from the machine, e.g., coin in, coin out, etc., are also supplied 
to the data communication node 42 via bus 220. The bus 220 connects connector 74 of the 
data communication node 42 and the connector 204 of the personality board 202 such that 
terminals having corresponding lettered suffixes are connected. For example, terminal 74C 
of connector 74 is connected to terminal 204C of connector 204 by a individual conductor 
within bus 220. All the other terminals are similarly connected by the bus 220. 

The network interface 49 of the data communication node 42 is also coupled to the 
personality board by a bus 222, as shown in FIG. 2. Bus 222 includes four conductors which 
connects the four terminals of connector 51 with four corresponding terminals of connector 
204, as indicated by the common lettered suffixes. It is over these four lines that the DCN 
controller 46 indirectly communicates with the floor controller. 

The serial machine interface 60 is also coupled to the personality board 202 by a bus 
224, as shown in FIG. 2. The bus 224 includes four conductors which couple four terminals 
62DD and 62EE of connector 62 with corresponding terminals 204DD and 204EE, 
respectively. It is over these four conductors that the DCN controller 46 communicates 
reconfiguration commands to the machine. The DCN controller transmits data through the 
terminal 204DD, which is provided to the machine on conductor MACHINE RX. The 
machine responds to the configuration command on the conductor MACHINE TX. The use 
of these two conductors will become more apparent in the description of the operation 
hereinbelow. 

Although buses 220, 222, 224 and 226 have been described as separate buses, the 
individual conductors within these buses could, and are in the preferred embodiment, 
combined into a single bus that is connected between the data collection node 42 and the 
personality board 202. To connect the data collection node 42 and the personality board 202 
a connector (not shown) is mounted on the data collection node 42 and a mating connector 
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(not shown) is mounted on the personality board 202. The two connectors are then mated 
together to connect the data collection node 42 to the personality board 202. The personality 
board is then coupled to the corresponding gaming device by a cable 225 (F1G.2). 

E. BONUS DISPLAY DRIVERS 

Referring now to FIGS. 10 and 1 1, two bonus display drivers are shown. The data 
communication node 42 is designed to support either of the display drivers. The data 
communication node 42 is coupled to the display driver of FIG. 10 through connector 228. 
An opto coupler 230 optically isolates the data communication node from a triac circuit 232 
which includes a triac 234. One terminal of the triac 234 is connected to a terminal 236B of 
a connector 236. Another terminal of the triac 234 is connected to a terminal 236C of 
connector 236. A bonus display such as a light or sound generating means is coupled across 
terminals 236B and 236C so that the triac 234 could drive the external bonus display 
responsive to an actuation signal from the data communication node 42. 

A second embodiment of the display driver is shown in FIG. 11. In this embodiment, 
the data communication node 42 is coupled to the driver circuit through connector 238. The 
driver circuit of FIG. 1 1 includes a relay 240 operatively coupled to a transistor 242. The 
relay 240 is a two-position relay which toggles between the two positions responsive to a 
current passing through transistor 242. The transistor 242 conducts a current responsive to 
an actuation signal received on terminal 238B from the data communication node 42. 

The display drivers are used by the data communication node 42 to activate a display 
on the gaming device which indicates that the machine is now in a bonus mode or condition. 

F. FLOOR CONTROLLER 

As shown in FIG. 1, the floor controller is directly connected to both the high speed 
network 38 and a plurality of gaming devices. The floor controller is responsible for 
monitoring the activity of each of the gaming devices connected thereto and reporting this 
activity to the database 32. In addition, the floor controller is responsible for transmitting a 
reconfiguration command to a selected one or more of the gaming devices during certain 
bonus conditions. These conditions will be described in detail in the operation section below. 

The floor controller is connected to the associated gaming devices by current loop 
networks. Because of the limitations of the current loop network, only a predetermined 
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number of gaming devices can be supported on any one current loop network. In the 
preferred embodiment, each current loop network supports up to 64 gaming devices. In order 
for each floor controller to support more than this predetermined number of gaming devices, 
each floor controller is equipped with a communication board 246, as shown in FIG. 12. The 
communication board 246 supports up to 16 separate current loop networks. The board is a 
standard size card that fits into one of the ISA card slots in the back of the floor controller. 
The board includes a male edge connector (not shown) which mates with a female back plane 
connector (not shown) in the floor controller. The back plane connector provides the floor 
controller CPU data, address, and control lines to the communication board 246 to enable the 
communication board and the floor controller CPU to communicate. 

The communication board 246 includes eight separate microcontrollers 248 A-248H. 
The microcontrollers communicate with the floor controller through ISA bus interface logic 
247 over buses 249 A and 249B. The microcontrollers are shown in a daisy-chain connection 
in FIG. 12, but any other equivalent interconnection scheme can be used. The data received 
from the floor controller microprocessor is passed between the microcontrollers from 248A 
to 248H, as indicated by the arrows. Each microcontroller is responsible for passing the data 
along and determining whether the data includes a message for a machine connected to its 
corresponding current loop networks. 

Each microcontroller is responsible for two current loop networks. Each 
microcontroller communicates with its associated gaming devices via two corresponding 
current loop networks. Two serial signal lines 251 connect each microcontroller to a current 
loop driver circuit 250. The driver circuit 250 provides the necessary current drive to support 
the current loop network. Each pair of serial signal lines 251 has a corresponding pair of 
current loop lines 253. The current loop driver circuit 250 can either be located on the 
communication board as shown in FIG. 12 or on a separate printed circuit board (not shown). 
If located on a separate board, the current loop driver circuit 250 can be connected to the 
communication board by a cable. 

In the preferred embodiment, the last microcontroller 248H is solely responsible for 
communicating with the floor controller microprocessor. All of the data received from the 
machines over the various current loop networks are passed along to the microcontroller 
248H by the associated microcontroller. The microcontroller 248H analyses the data and 
determines whether the data needs to be communicated to the floor controller. If not, the last 




26 



microcontroller records the communication but does not forward the data to the floor 
controller. This helps off-load some of the floor controller communication processing to the 
communication board. 

n. OPERATION 

The above-described system allows a casino in which the system is installed to run 
promotions on any properly equipped gaming machines while simultaneously gathering 
player tracking and accounting data from all machines. The system provides the capability 
for the casino to select which of the plurality of machines are used in any given promotion. 
The system further allows any number of different promotions to operate simultaneously. 

Each promotion involves sending a reconfiguration command from the floor 
controller to a gaming device that has been selected to be part of a given promotion over the 
associated network. Upon receipt of the reconfiguration command, the gaming device 
reconfigures its payout schedule in accordance with the received reconfiguration command. 
As described above, reconfiguring a gaming device payout schedule, in the preferred 
embodiment, includes activating a bonus payout schedule that pays out bonus amounts in 
addition to the amount determined by the device payout table. 

A partial list of the promotions according to the invention include, but are not limited 
to: a multiple jackpot wherein the gaming device reconfigures its payout to be a multiple of 
its default payout schedule; a bonus jackpot wherein the gaming device reconfigures its 
payout schedule to payout an additional bonus amount when certain conditions are met; and a 
progressive jackpot wherein two or more gaming devices are combined in a progressive 
jackpot having a progressive jackpot payout schedule. In addition to these, many other 
promotions are possible by the above-described system for controlling and monitoring a 
plurality of gaming devices. 

The system 10 also allows for improved player tracking. As with standard player 
tracking, the above-described system monitors and reports how many coins are played by 
each player. The system 10, however, also includes the ability to record how long each 
player spends at each machine and the number of coins won, games played, and hand 
jackpots won by each player. All this information is stored on the database, which can be 
later analyzed for future targeted direct mailing campaigns. The player tracking according to 
the invention also allows the casino to schedule buses and other groups and measure their 
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profitability. The system also allows for cashless play as well as advanced accounting and 
security features. 

Another feature of the above-described system is jackpot announcements. The 
jackpot announcement feature displays a message on a reader board or display located in the 
casino which announces a jackpot as soon as a jackpot is won, i.e., as soon as the reels stop 
spinning. The floor controller generates the jackpot announcement once a DCN connected 
thereto indicates a jackpot is won. An example of such a message might be: "Now paying on 
machine 1342, a jackpot of $300." With prior art data collection systems, the amount of the 
jackpot is only known after the payment is made. Even then the system must account for 
partial pays, hopper empty, etc. 

An advantage of the current system over prior art systems is the ability to implement 
better tournament systems. In a slot tournament, players pay a fee to play. All play during 
the session is free. The players accumulate credits instead of cash. The person with the most 
credits at the end of the tournament wins. Games are usually manually altered to provide 
payouts of 200 to 300% to make the games more fun. The games are altered manually by 
replacing the read only memory (ROM) in the gaming devices. 

One exciting aspect of tournament play is to see who is ahead. No current system can 
display this information in real time. This is because current systems can only measure 
winnings as they are added to the credit meter or paid from the hopper (some casinos use 
tournament tokens instead). Since credits are usually added at a rate of 10 per second, a 
1,000 credit win can take 100 seconds to register. Casinos attempting to create display 
boards showing who is ahead are frustrated by the lag time. The jackpot announcement of 
the invention allows casinos to display the player with the most credits by comparing the 
number of credits for each player. This comparison and display is performed real time as 
each transaction is completed. 

In order to implement each of these features, the various computers and 
microcontrollers each execute software or firmware. This software and firmware routines are 
described below. These routines are described with reference to accompanying flow charts. 
These flow charts would enable one of ordinary skill in the art of computer programming to 
write a corresponding computer program which the computer or microcontroller could 
execute. 
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A. DATA COMMUNICATION NODE 

1. Power Up Procedure 

Referring now to FIG. 13, a power up procedure 252 for the data communication 
node is shown. This procedure is executed by the DCN controller 46 when initially powered 
up. The first step of the procedure is to validate the RAM to ensure that it is not corrupted 
and to set up all the DCN hardware. Validating the RAM involves writing known patterns of 
Is and Os to the DCN RAM. This RAM can either be internal to the DCN controller 42 or 
external as shown in FIG. 2. Setting up the DCN hardware includes initializing timers and 
interrupts. 

Next the DCN controller checks the RAM in step 255 by reading the pattern of Is and 
Os back out of the RAM to ensure that the RAM is fully functional. If the RAM turns out to 
be defective the DCN controller goes into an endless loop in 256. 

2. Reading Unique Identification number 

If the RAM is fully functional, the DCN then reads the unique identification number 
from the personality board. As described above, this unique identification number is stored 
in a nonvolatile memory 210 on the personality board. Reading the unique ID number out of 
the nonvolatile memory involves following the memory manufacturer's interface protocol as 
specified in the nonvolatile memory data sheet. The unique identification number provides a 
means for uniquely identifying the gaming device. 

After the unique ID has been read from the personality board, the DCN processes the 
discrete machine inputs in step 260. This step will be described in further detail in 
Subsection 3, Monitoring Gaming Device Discrete Input below. After the discrete 
inputs have been processed in step 260, the DCN processes the machine serial interface in 
step 262. This step is described further below in Subsection 4, Processing Gaming Device 
Serial Interface. Next, the DCN processes the network interface, i.e., the interface 
between the DCN and the floor controller connected thereto. The process network interface 
step 264 is described further below in Subsection 5, Processing Network Interface. 
Finally, the DCN processes the player tracking interface in step 266. This step is described 
below in Subsection 6, Processing Card Insertion. At the completion of step 266 the 
DCN loops back to step 260 and continuously, sequentially executes steps 260-266. 
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3. 



Monitoring Gaming Device Discrete Input 



Referring now to FIG. 14, the DCN step of monitoring the gaming device discrete 
inputs 260 will now be described. The DCN first reads the discrete inputs on input lines 76 
in step 267. One particular set of discrete inputs is shown in FIGS. 4 and 9 for a particular 
gaming device. The actual discrete inputs present will depend on the machine type, as 
indicated by the configuration number, which is also read by the DCN controller 46. Most 
gaming devices provide at least some of the following discrete inputs: coins in, coins out, 
coins to drop, games played, attendant paid jackpots, slot door, drop door, progressive 
jackpots, and bill validators. The system supports all of these discrete inputs as well as 
others. 

The DCN keeps track of the machine activity by maintaining several meters in 
memory. Each meter, in the preferred embodiment, includes six digits. Moreover, to 
improve the reliability of the system, the DCN maintains redundant backup copies of these 
meters with an order to replace the original meters in the event that the originals are 
corrupted. In step 268, the DCN increments the meters as required based on the discrete 
inputs. The meters are maintained even in the event that the DCN is disconnected from the 
floor controller. Once the DCN is reconnected to the floor controller, all the activity level 
information is then available. Step 268 will be discussed further below. 

Next, the DCN processes the drop door signal in step 270. The drop door signal 
DROP DOOR indicates that the drop door on the machine has been opened. This is an 
important event and is therefore processed separately. 

In step 272, the DCN validates the meter values to determine whether the values 
stored in the meters are valid. The DCN checks whether the meter values are valid in step 
274. In the preferred embodiment, a check sum is maintained for each meter value. Thus, 
the DCN in step 274 checks to see whether the check sum is correct based on the current 
meter value. If the meter values are okay, the discrete input monitoring step 260 is complete. 
If the meter values are not valid, the DCN replaces the meter values with the redundant back 
copy of the meter values in step 278, and then the step 260 is complete. 

Referring now to FIG. 15, increment meter step 268 is shown in further detail. The 
sequence shown in FIG. 15 is repeated for each meter value that has changed. The first step 
is to adjust the meter value based on the discrete inputs and to calculate the associated check 
sum. Next, the DCN determines whether the particular meter has an active associated 
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countdown count in step 282. Some games or promotional activities require the player to 
reach a certain level of activity in order to be eligible for certain bonus points. These 
countdown counts are used to determine whether the player has achieved this level of 
activity. For example, the player may be required to play a certain number of coins before 
being awarded any points. If the countdown count is active, the DCN adjusts the current 
players count down values in step 284 based on the corresponding adjustment of the 
associated meter. 

In step 286, the DCN sets the current message to the count down message. The count 
down message indicates to the player when he or she will be eligible for the bonus points. 
Finally, in step 288 the DCN sets the current bezel color and rate to a count down color and 
rate. This color and rate information is subsequently transmitted to the player tracking node 
for processing, as described further below. The countdown color indicates the bezel color 
and the count down rate indicates that flashing rate of the bezel color displayed during the 
count down message. 



Referring now to FIG. 16, a process 262 for processing the gaming device serial 
interface is shown. The serial machine interface 60, as shown in FIG. 2, allows the DCN 
controller 46 to communicate with the gaming device through the personality board. This 
serial machine interface allows the DCN controller 46 to transmit reconfiguration commands 
to the gaming device in order to reconfigure the payout schedule of the machine in 
accordance with the reconfiguration command. In addition, the serial machine interface 
provides an additional means for determining the activity level of the gaming device. Instead 
of reading the discrete machine inputs, the DCN controller 46 can transmit a status request 
command to the machine over the serial interface and the machine can respond back with the 
requested status information. 

Any communication protocol can be used to implement this communication path over 
the serial machine interface, as is known in the art. An example of one such protocol uses a 
data packet including a command code, a message sequence number, a CRC, and a variable 
length message. In the preferred embodiment, either the DCN controller 46 or the machine 
can initiate communications over the serial machine interface. However, if the machine 
detects that the DCN is trying to send a message to the machine, the machine must abort its 
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message and attempt to resend the message at a later time. 

The preferred embodiment of the system supports many different reconfiguration 
commands. A partial list of the reconfiguration commands is given below in Table 1. These 
reconfiguration commands are sent from the DCN controller 46 to the machine over the 
serial machine interface wherein the machine reconfigures its payout schedule in accordance 
with the particular reconfiguration command. The reconfiguration commands do not 
originate with the DCN, instead the reconfiguration commands originate from the floor 
controller and are transmitted to a particular machine over the associated current loop 
network or the command can originate at one of the other computers on the high speed 
network. The DCN is simply responsible for forwarding the reconfiguration command onto 
the gaming device on receipt of the reconfiguration command over the associated current 
loopnetwork coupled between the floor controller and the DCN. 

Examples of Reconfiguration Commands 
Bonus Pay From Hopper (Coin Format) 
Bonus Pay to Credit Meter (Coin Format) 
Bonus Pay from Hopper (Dollar Format) 
Bonus Pay To Credit Meter (Dollar Format) 
Add Non-cash outable credits to Game 
Begin Double Jackpot Time 
Stop Double Jackpot Time 



The actual process of processing the machine serial interface begins in step 
292 wherein the DCN polls the machine to determine its level of activity. This 
polling step includes sending a status message from the DCN to the machine over 
the serial machine interface. In response, the machine will send a packet of status 
information indicating the current amount of activity on the machine. The status 
information included in the response will depend on the type of machine that the 
DCN is communication with. 

The data communication node 42, in step 294, waits for a reply to the status 
request. If a reply is received, the DCN indicates that the machine is "on line" in 
step 296 and processes the machine reply in 298. The step of processing the 



Table 1 -- 
1. 



5. 
6. 
7. 
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machine reply includes updating the meter values, as done when processing the 
discrete inputs. After the machine reply has been processed, the process 262 is 
complete. 

If the DCN does not receive a reply from the machine in step 294, the DCN 
indicates that the machine is "off line". The DCN will wait for a predetermined 
amount of time before deciding that the reply is not received. In the preferred 
embodiment, this predetermined period is approximately 110 milliseconds. 
5. Processing Network Interface 

Another step in the DCN power up procedure 252 is the step of processing 
the network interface 264. This step is described with reference to FIGS. 17-19. 
The network interface refers to the current loop that connects the particular DCN 
with the associated floor controller. The following description assumes that the 
DCN has received a valid message from the associated floor controller. Because 
there are multiple 

DCNs connected to any one current loop, the floor controller must include some 
means for addressing a particular machine. 

Although each machine includes a unique identification number which 
could be used as the actual address for each DCN on the current loop, it is 
unnecessary to use the unique identification as the actual address because there 
are only a limited number of DCNs connected to each current loop. Accordingly, 
in the preferred embodiment of the invention, the floor controller uses a shorthand 
token representation of the DCN's unique identification number to address the 
DCN. In the preferred embodiment, a single byte address is used to address a 
DCN on any given current loop. This one-byte address allows up to 256 DCNs to 
be supported on any given current loop network. In the preferred embodiment, 
however, only 64 such DCNs are connected to a single current loop and therefore 
the single byte address is more than adequate. The single byte address 
substantially reduces the amount of traffic on the current loop network by 
reducing the number of bytes from four in the unique identification number to one 
for the shorthand token representation. 

The floor controller is responsible for generating the unique single byte 
address for each data communication node on a given current loop network. The 
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process of assigning unique single byte addresses to the DCNs is described below 
in Section C. 

Once all the DCNs have been assigned a unique address, the DCN can 
begin monitoring the current loop network for messages addressed to it. If the 
DCN detects a message addressed to it, the DCN executes step 264. The DCN 
first checks to see whether the message is valid in step 304. This check is done by 
computing the CRC value of the message and comparing it to the CRC included 
with the message. If the two CRCs match, the message is valid and the DCN 
processes the network message in step 306. Processing the network message is 
described further below with reference to FIGS. 18 and 19. Once the message has 
been processed, the DCN sends a reply back to the floor controller over the 
current loop network in step 308. The actual substance of the reply will depend 
on the message received in step 306. If the message is invalid, the DCN does not 
reply. 

Referring now to FIG. 18, the first step of processing the network message 
is to determine what type of message was sent from the floor controller in step 
312. There are three basic types of messages that the floor controller sends to the 
DCN. The first is a request for data from the DCN. If this type of message is 
detected the DCN builds the data requested and transmits the data in a reply 
message. The main use of this message type is to gather status and meter 
information from the DCN. 

Another type of message is one including configuration data for the DCN. 
This message allows the floor controller to implicitly set the DCN's memory to a 
fixed value. This message is used to override the DCN's internal variables, e.g., 
to get a DCN out of a lock-up condition, or to download new firmware to the 
DCN for execution. On receiving this type of message, the DCN simply 
overwrites its memory with the configuration data included in the configuration 
message in step 316. The DCN then builds an appropriate acknowledgment and 
transmits this acknowledgment message to the floor controller in step 320. 

The other type of message is one sent in response to a DCN request. The 
DCN processes this data in step 318, which is described further in FIG. 19. If the 
message includes either the configuration data or the data in response to a DCN 
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request, the DCN builds an acknowledge message in step 320 and transmits this 
message to the floor controller. 

The step of processing a floor controller message sent in response to a DCN 
request will now be described with reference to FIG. 19. The first step of 
processing this type of message is for the DCN to determine what type of data is 
included in the message. Once again there are three types of data that can be 
included in this message type: a reconfiguration command, card data, or other 
minor dattf> The DCN makes this determination in step 324 by analyzing one of 
the bytes in the data packet of the message. This byte will be referred to herein as 
the command byte. If the command byte indicates that the message contains 
reconfiguration data, i.e., the command byte equals a reconfiguration command, 
the DCN stores the reconfiguration data in a predefined data structure in memory. 
Listed below in Table 2 is an example of a data structure for storing the 
reconfiguration data. 



2 — Reconfiguration Data Structure 
Bonus Type 
Mystery Jackpot Data: 

A. Number of coins to award 

B. Number of seconds to award 

C. Pay award to 
Bonus Time Data 

A. Jackpot Multiplier 

B. Jackpot Payout Limitations 

C. Number of Seconds to Keep Bonus Time Active 

D. Minimum Activity Level 

The bonus type field of the data structure indicates the type of bonus state 
the machine is to be placed in. Examples of potential bonus modes include 
progressive/nonprogressive, multiple jackpot, or mystery jackpot. If the mystery 
jackpot is indicated, the mystery jackpot data included in the structure specifies 
the conditions under which the mystery jackpot is paid out. The mystery jackpot 
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can be set to payout, e.g., after a certain number of coins in, handle pulls, which is 
specified by subfields of the mystery jackpot data. 

The bonus time jackpot is a promotion wherein the machine pays out more 
than that dictated by its default payout schedule. In one embodiment of the bonus 
time promotion, the payout schedule of the machine can be modified to be a 
multiple of its default to payout schedule, as specified in subfield (A) of the bonus 
time data. This promotion can be used to encourage gaming activity during off- 
peak hours, e.g., midnight to 4 a.m. on weeknights. Alternatively, the bonus time 
promotion can be activated on a random basis. The timing of the multiple jackpot 
is specified by the casino on one of the computers connected to the network. The 
bonus time data also specifies the conditions under which the player becomes 
eligible for the bonus time jackpot. The subfield (B) of the bonus time data 
specifies whether the player is eligible for the bonus time data only if the player is 
playing the maximum coin in the machine. Subfield (C) limits the bonus time 
promotion to a predetermined number of seconds. This field limits the bonus 
time promotion to a predetermined number of seconds; if the player does not hit a 
jackpot within this specified time period, the bonus time promotion concludes. 
The minimum activity level can also be specified in subfield (D). This field can 
be used to specify the minimum activity level required by the player in order to be 
eligible for the bonus time jackpot. For example, the player can be required to 
play at least 20 coins over the last three minutes in order to be eligible for the 
bonus time jackpot. An indicator light on the player's machine can be used to 
indicate when the player reaches the minimum activity level and thereby becomes 
eligible for the bonus time jackpot. 

In another embodiment of the bonus time promotion, a bonus amount is 
awarded in addition to the payout according to the default of the payout schedule 
of the machine. The amount of the bonus jackpot is specified in subfield (E) of 
the bonus time data. For example, this bonus time promotion might include five 
bonus amounts of $10, $25, $50, $100 and $500, which is specified by subfield 
(E). When a player hits a particular jackpot, whichever bonus amount is specified 
by the bonus amount subfield this amount is automatically paid out in addition to 
the payout amount determined by the machine's default payout schedule. This 
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bonus time promotion can also be used in combination with subfields (C) and (D) 
to specify the conditions under which the player is eligible for this bonus time 
jackpot award. 

After the DCN has stored the reconfiguration data in step 326, the DCN 
will then send the appropriate reconfiguration command to the machine over the 
serial machine interface in step 328. The machine, responsive to the received 
reconfiguration command, reconfigures its payout schedule in accordance with 
the received reconfiguration command. For example, if the reconfiguration 
command specifies a multiple jackpot condition, the machine will reconfigure its 
payout to be a multiple of its default payout schedule. The machine will 
reconfigure its payout schedule in a similar manner for the other bonus types. 

The other type of data that can be included in a response from a DCN 
request is card data or player tracking data. This data is sent to the DCN in 
response to a status message from the DCN to the floor controller wherein the 
status message indicates that a player card has been inserted. Included in this 
message is the card ID number detected by the card reader. In response to this 
status message the floor controller will transmit a card insertion message to the 
DCN. The card insertion message includes information associated with the 
particular player ID number. An exemplary card insertion message data packet is 
listed below in Table 3. 



TABLE 3 Card Insertion Message Data Packet 

1. Card Identification Number 

2. Player First Name 

3. Player Last Name 



Upon receipt of the card insertion message, the DCN stores the player's 
name and points in order for this information to be displayed on the VFD display 
associated with the player tracking node. Then, a DCN sets the current message 



4. 



Current Point Balance 



5. 



Casino Code 
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to a data received message in step 334. Finally, a DCN sets the current bezel 
color and bezel rate to a data received bezel color and bezel rate in step 336. The 
bezel color specifies the bezel color to be displayed by the card reader and the 
bezel rate specifies the flashing rate of the card reader LEDs. This bezel 
information is subsequently transmitted to the player tracking node for processing 
thereby. 

The final data type that can be included in the message sent from the floor 
controller in response to a DCN request is generically classified as other minor 
data. This data includes general system or DCN specific information such as 
display information. 

6. Processing Player Tracking Interface 

The next step in the DCN process is processing of the player tracking 
interface 266. The DCN maintains a variable that indicates what message is to be 
sent to the player tracking node. This variable is referred to as the current 
message variable. Before transmitting a message to the player tracking node, the 
DCN first checks this variable to see which of a plurality of messages should be 
sent to the player tracking node. 

The process 266 begins in 340 by sending the current message to the player 
tracking node that is specified by the current message variable. In addition to the 
current message, the DCN sends the bezel color and bezel rate information to the 
player tracking node. The bezel color and bezel rate information could have been 
specified by the floor controller or by the DCN itself. 

Next, the DCN determines the card status in step 342. If there is no card 
inserted in the card reader, the DCN sets the current message variable to an attract 
message. This message specifies that the player tracking node is to display a 
message which will attract players to the machine. Similarly, the DCN sets the 
current bezel color and bezel rate to an attract bezel color and rate in step 346. 
This attract color and rate is part of the attract message that will be sent to the 
player tracking node when the current message is sent. 

If the DCN determines that a good card has been inserted in the card reader, 
the DCN processes the valid card in step 350. This step is described further 
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below with reference to FIG. 21. 

If, however, the card status indicates that a bad card has been inserted, i.e., 
an invalid card number, the DCN sets the current message variable to specify a 
card error message in 352 and the DCN sets the current bezel color and bezel rate 
to a card error color and rate in 354. This card error information is included with 
the card error message that is sent to the player tracking node when the current 
message is sent. 

7. Processing Card Insertion 

Referring now to FIG. 21, the process 350 for processing a valid card 
insertion is shown. The first step that the DCN executes is to determine whether 
the card data corresponding to the valid card has been received from the floor 
controller in step 356. If not, the DCN builds a network request message for the 
player name and points associated with the card ID number in step 358. Next, the 
DCN sets the current message variable to specify a card inserted message is to be 
transmitted in step 360. Finally, the DCN sets the current bezel color and rate to a 
card inserted color and rate, which indicates to the player that the system is still 
processing the card number. This information is sent to the player tracking node 
when the current message is sent. 

If the card data has been received from the floor controller, the DCN then 
determines in step 366 whether player tracking has started for the particular 
player. If player tracking has not yet started, the DCN sets the current message 
variable to the data received message in step 368 and sets the current bezel color 
and rate to data received color and rate in step 370. If player tracking has started, 
the DCN processes the player tracking in step 372, as described with reference to 
FIG. 22. 

Processing player tracking 372 begins with the step of determining whether 
the player has received new points in 374. These points can be considered 
roughly as the equivalent of "frequent flyer miles" used by airlines. These points 
allow the system to run promotionals whereby individuals are given points or 
credit associated with their card that can be redeemed toward the purchase of 
goods or services offered by the casino. Typically these points are redeemed at a 
redemption counter in the casino for meals or clothing, for example. The points, 
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therefore, are an additional inducement to encourage play. 

The player tracking system of the invention allows the casino to determine 
how and when the player is issued points. The casino can specify the type and 
number of coins that must be played before a player is awarded a given number of 
points. The system uses this specified information to inform the player of his or 
her progress towards receiving additional points. The system encourages play by 
informing the player of how many additional coins must be played before 
receiving additional points. For example, a player who is only one coin away 
from receiving points, but who desires to stop playing, may decide to play "one 
last coin" in order to receive the points. The system informs the player by 
displaying a message on the vacuum florescent display indicating how many 
coins the player is away from receiving additional points. 

Referring now to FIG. 22, player tracking 372 begins with the step of 
determining whether the player has received new points in 374. If no new points 
have been received, the DCN sets the current message variable to specify a 
countdown message in step 376 and sets the current bezel color and bezel rate to a 
countdown bezel color and rate in step 378. 

The countdown bezel color and rate indicates the player's progress towards being 
awarded additional points. 

If new points have been received, such as where the player has played a 
given number of coins, the DCN sets the current message variable to a points won 
message in step 382 and sets the current bezel 

color and rate to a points won color and rate in step 384. The points won message 
informs the player of the number of points won. 

The above-described tracking process provides a means for providing 
visual feedback to the player inserting the card into the card reader. By 
modifying the bezel color and bezel rate, the data communication node provides 
immediate feedback to the player concerning the proper insertion of the card. If 
the player inserts the card properly into the card reader so that the card reader 
senses a valid user identification number, the card reader provides positive visual 
feedback to the user by illuminating the bezel. On the other hand, if the user 
improperly inserts the card so that the card reader cannot read the user 
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identification number, the card reader can provide negative visual feedback to the 
player by illuminating the bezel with a different color and/or flashing rate. In the 
preferred embodiment, this positive visual feedback includes flashing the green 
LEDs to produce a flashing green signal around the card reader opening. The 
negative visual feedback includes flashing the red LEDs. A third combination 
color is used during the processing of the player tracking information. This 
process provides immediate feedback to the player concerning the insertion of the 
card in the card reader. 



The system described above allows for improved player tracking by 
recording each and every machine transaction including: time of play, machine 
number, duration of play, coins in, coins out, hand paid jackpots and games 
played. The player tracking is conducted over the same network as the 
accounting data is extracted. This allows the invention to provide bonusing to 
certain individual players as well as during certain times. As with standard player 
tracking, the above-described system monitors and reports how many coins are 
played by each player. The system according to the invention, however, also 
includes the ability to record how long each player spends at each machine and 
the number of coins won, games played, and hand jackpots won by each player. 
The system is able to record all this information because the it operates on a 
transaction by transaction basis. Each transaction, whether it be a coin in, a 
handle pull, etc., is recorded by the system. Other prior art systems simply 
compile the player tracking information at the completion of play. 

All the transaction information is stored on the database, which can be later 
analyzed for future targeted direct mailing campaigns. The player tracking 
according to the invention allows the casino to schedule buses and other groups 
and measure their profitability. Because the system records each transaction, the 
casino can reconfigure their casinos to better match the tastes and demands of 
their customers. 

The improved player tracking according to the invention also allows the 
casino to calculate theoretical wins exactly because the system always includes 
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the most current information. The operation of the player tracking procedure is 
described below. 

1 . Power Up Procedure 

The operation of the player tracking module will now be described with 
reference to FIG. 23 where the powerup process 400 for the player tracking node 
is shown. As in the data communication node, the player tracking node first 
validates the RAM and sets up its associated hardware in step 402. Next, the 
player tracking node tests the RAM in step 404 to determine whether the RAM is 
functioning properly. If not, the player tracking node, i.e., player tracking 
controller, terminates its program in an error condition in step 406. If the player 
tracking RAM is fully functional, the player tracking node sequentially executes 
steps 408-414. In step 408 the player tracking controller processes the DCN 
interface between the player tracking controller and the DCN controller. In step 
410 the player tracking controller updates the player tracking display. In step 412 
the player tracking controller updates the bezel. Finally, the player tracking 
controller processes the card reader in step 414. Each of these steps will now be 
described further below. 

2. Processing DCN Interface 

Referring now to FIG. 24, the steps for processing the DCN interface are 
shown. First, the player tracking controller checks for a new message received 
from the DCN in step 416. If a new message has been received, the player 
tracking controller overwrites its current message buffer with the new message 
and updates the bezel color and rate values with those contained in the new 
current message. Then, the player tracking controller builds a card status reply 
message in step 420. The card status message indicates whether a card has been 
inserted and if so whether the card was a good card or a bad card, i.e., the card 
was read properly by the card reader. If a valid card, the card status reply 
message also includes the identification number encoded on the card. This step 
might also involve transposing the number encoded on the card depending on the 
orientation in which the card was inserted into the card reader. This card status 



42 



reply message in then sent to the DCN in step 422. 



3. Processing Display Update 
The process of updating the player tracking display is shown in FIG. 25 at 
410. This process begins with the player tracking controller scanning the display 
message for display attribute information. Examples of such display attribute 
information is given below in Table 4. Each display attribute specifies a different 
graphic mode for the player tracking display. 



TABLE 4 - Display Attribute Information 



1. 


Flash Rate 


2. 


Center Display 


3. 


Set Display Intensity 


4. 


Use Small Lower Font 


5. 


Use Small Upper Font 


6. 


Use Normal Large Font 


7. 


Set Pause Time 


8. 


Set Scroll Speed 


9. 


Center and Melt 


10. 


Center and Scroll Down 


11. 


Center and Scroll Up 


12. 


Scroll Down and Stop 


13. 


Scroll UP and Stop 


14. 


Scroll Left and Stop and End of Message 


15. 


Scroll Down 


16. 


Scroll Up 


17. 


Scroll Right 


18. 


Scroll Left 


19. 


Reverse Video 


20. 


Normal 



The player tracking controller then determines whether any such attribute 




information is found in the display message. If so, the player tracking controller 
sets up the display driver to incorporate the graphics mode specified by the 
attribute information. The player tracking controller then strips out any display 
attribute information from the display message in step 432 because the display 
attribute information is embedded in the display message. The remaining data in 
the display message is the actual text to be displayed by the player tracking 
display, e.g., the player's name. The player tracking controller then sends this 
text to the display in step 434, which is then displayed by the player tracking 
display. 

4. Processing BezelUpdate 

The player tracking node is also responsible for updating the bezel, both in 
terms of its color and flashing rate. This process 412 is shown in FIG. 26. The 
first step in processing the bezel update is to determine to bezel color as specified 
by the DCN and then drive the appropriate LEDs in the card reader. As described 
above, the preferred embodiment of the card reader includes dual diodes having 
two primary colored diodes that 

can be driven separately or in combination to produce three different colors. 

Next, the process determines the bezel rate as specified by the DCN. In a 
first case, the bezel rate is zero or off and thus the player tracking controller turns 
the LEDs off in step 442 in this case. If the bezel rate specifies a flashing rate, the 
player tracking controller flashes the bezel at the appropriate bezel rate in step 
442. Flashing the bezel involves turning the LEDs on and off at the specified 
rate. This can be accomplished by a timer interrupt or a timing loop executed by 
the player tracking controller. The final option is that the rate can be infinite or 
effectively a solid bezel color. In this case, the player tracking controller simply 
leaves the card reader LEDs on in step 446. This completes the processing bezel 
update process 412. 

5. Processing Card Reader 

The next process step for the player tracking node is to process the card 
reader. This process 414 is shown in FIG. 27. The first step is for the player 

44 




tracking controller to determine the card status in 450. In the preferred 
embodiment, the card status is determined by comparing the checksum of the 
card, as read off the card by the card reader, to a computed checksum of the data 
read off the card. Other methods of determining card status can be used as well 
depending on the type of card reader employed. 

If the player tracking controller determines that a valid card was inserted in 
the card reader, the player tracking controller sets a card status variable equal to 
good card. This card status is then subsequently transmitted to the DCN 
controller. Then, the player tracking controller sets a card ID variable equal to the 
identification number read by the card reader in step 454. The card status and the 
card ID provide the DCN with sufficient information to instigate the player 
tracking. 

If, on the other hand, the card reader indicates that the card was read 
improperly or that the card is an invalid card for the card reader, the player 
tracking controller sets the card status variable to bad card in step 458 and the 
card ID variable is cleared in step 460. If neither a valid or invalid card condition 
was detected in 450, the player tracking controller sets the card status variable to 
no card in step 462 and clears out the card ID in 460. 

C. FLOOR CONTROLLER 

1 . Power Up Procedure 

Referring now to FIGS. 28-32, the process 464 operable on the floor 
controller will now be described. The process 464 is shown in FIGS. 28-32 in 
flow chart forms. These flow charts would enable one of ordinary skill in the art 
to implement the process in computer software using an appropriate computer 
programming lariguage. 

The floor controller process 464 begins at step 466 by opening the database 
tables in the file server. As described above, the file server includes a 
commercially -available database program which stores the machine activity 
information as well as player tracking information and associated system 
characteristic parameters. This step 466 can also include fetching some or all of 
these system characteristics in order to trigger certain events such as bonus 
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jackpots, as described below. 

In step 468, the floor controller terminates any active player tracking 
sessions in the database. Because player tracking may have been in progress 
when the floor controller became inoperable, when the floor controller powers up 
or becomes operable, there may be player tracking sessions initially active. In 
this step, the floor controller terminates any such active player tracking sessions 
in order to place the database in an initial state. 

Another step that the floor controller executes after becoming operable is to 
place an initial machine search message in an output message queue 470. This 
search message is used by the floor controller to determine which machines are 
connected to the floor controller. This output message is subsequently 
transmitted to all of the machines coupled to the floor controller using a global 
message format, as described below with reference to FIG. 31. In the preferred 
embodiment of the invention, the message handling is through the use of message 
queues. Furthermore, the preferred embodiment is both an output queue for 
outgoing messages from the floor controller to the machines and an input message 
queue for messages coming from the machines to the floor controller. Queues are 
well-known data structures in the art of computer science and are therefore not 
further discussed herein. Alternatively, the message-handling could be done 
without the use of the queues. In such an embodiment the outgoing messages 
would be sent immediately rather than being queued, and any incoming messages 
would be processed immediately. 

The bulk of the work performed by the file server process 464 is performed 
in message processing step 472. In this step, the floor controller processes all 
messages sent to or received from the machines connected thereto. This step will 
be described further below with references to FIGS. 29 through 31. 

The process 464 also includes a system monitoring step 474. This system 
monitoring step 474 administers certain system- wide events. These system- wide 
events include the counting-related events and bonusing events. The floor 
controller continuously checks to see whether any of these events have been 
triggered. If any event has been triggered, such as a bonusing event, the floor 
controller takes the appropriate action to handle the event. The event may be 
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triggered by the time and day or 

by user intervention or other event. The system monitoring step 474 will be 
described further below with reference to FIGS. 32 and 33. 

The final step in process 464 is for the floor controller to check for a 
termination condition in step 476. In the preferred embodiment, the floor 
controller checks to determine whether an ESCape key as pressed. If an ESC key 
was pressed, the floor controller terminates the process 464. If no ESC key was 
pressed, the floor controller loops back to step 472 wherein the message- 
processing step and the system monitoring step are repeated. The floor controller 
continues in the loop 472-476 until the termination condition is sensed. 



As described above, the floor controller acts as a gateway between the 
machines connected thereto and the file server, as shown in FIG. 1. The floor 
controller is responsible for forwarding the machine activity received from the 
various machines to the database. The floor controller accomplishes this 
communication through the use of messages. The message processing step 472 is 
shown in more detail in FIG. 29. 

The first step in processing the messages is for the floor controller to send 
any messages that are queued-up in the output message queue to the appropriate 
data communication node in step 480. As described above, the output message 
queue is a simple data structure that is used to store any pending messages. 
Included in the message is a destination address by which the floor controller can 
determine which of the plurality of data communication nodes to send the 
message to. Next the floor controller receives any incoming messages from the 
data communication nodes coupled to the floor controller in step 482. Once an 
incoming message has been received, the floor controller parses through the 
message data included in the incoming message in steps 484 through 486. In the 
preferred embodiment, the floor controller parses through the message data one 
byte at a time. Thus, in step 484 the floor controller reads the next byte in the 
incoming message, and in step 486 the floor controller checks to see whether this 
is the last byte in the message. In the preferred embodiment, the message 
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includes a message length field which indicates the number of data bytes included 
in the message. In this case, a floor controller in step 486 checks to see whether 
the number of bytes read in step 484 is equal to the number of bytes specified by 
the message length field. 

Once the input message data has been parsed out of the incoming message, 
the floor controller takes the appropriate match in response to the message data in 
step 488. This step is described further below with reference to FIGS. 30 and 31. 
Following the message-handling step 488, the floor controller checks in step 490 
to determine whether any response is pending. The floor controller makes this 
determination by checking a transactions-in-progress structure which indicates 
whether the floor controller needs to respond to any previous message. If a 
response is pending, the floor controller queues up an appropriate outgoing 
message in the output message queue in step 492. Otherwise, the floor controller 
completes the message processing step 472. 

Referring now to FIG. 30, the message-handling step 488 is shown in more 
detail. The message-handling step begins by verifying that the message data 
corresponds to a valid message in step 496. In the preferred embodiment, the 
message includes a cyclical redundancy check (CRC) by which the floor 
controller can determine whether the message is valid or corrupt. Only if the 
message is valid will the floor controller perform any additional message- 
handling steps. The floor controller also parses through the message in step 496 
to determine what type the message is. The message type determines the 
appropriate floor controller action. In the preferred embodiment, the messages 
include a command code which indicates the type of message. 

The first type of message can be one which includes new meter 
information. The floor controller checks in step 498 to determine whether the 
message includes this type of information. If the message includes new meter 
information, the floor controller saves the new meter information locally in step 
500. The floor controller maintains local copies of the meter information in order 
to minimize the amount of traffic on the high-speed network. Because the 
machine meters change so rapidly, forwarding this new meter information on to 
the file server each time one of these meters is altered would produce an excessive 
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amount of network traffic on the high-speed network. Therefore, in the preferred 
embodiment, the floor controller saves this new meter information locally in step 
500 and only forwards the new information on to the file server after a 
predetermined amount of time has elapsed. 

Another type of message is one which requests data. The floor controller 
checks in step 502 to determine whether the message type is one requesting data. 
Typically, these data requests will be for player tracking information such as 
where a player inserts a card into a card reader whereupon the data 
communication associated therewith sends the identification number encoded on 
the card to the floor controller requesting the player tracking data associated with 
the player identification number. If the floor controller detects a data request in 
step 502, the floor controller looks up the requested data in the database on the 
file server in step 504. Also, in step 504, the floor controller marks a response 
pending in the transactions in progress structure to indicate that this requested 
data needs to be sent back to the DCN. As described above, the floor controller 
queues up outgoing messages responsive to the transactions in progress structure. 

Another message type is one used by the floor controller to establish new 
machine addresses. The floor controller periodically checks to determine whether 
any new DCN has been coupled to its associated current loop networks in order to 
assign a unique address to that machine. In step 506, the floor controller checks 
to see whether the incoming message is in response to such a process. If the 
incoming message is in response to a machine search, the floor controller assigns 
a new machine address to the responding machine in step 508. The entire 
process of assigning new machine addresses is described below with reference to 



Finally, the floor controller in step 510 handles any miscellaneous 
messages. These miscellaneous messages are used primarily for debugging and 
trouble-shooting the machines. 

3. Assigning Gaming Device Addresses 
As described above, in the preferred embodiment of the invention, the floor 
controller uses a shorthand token representation of the DCN's unique 
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identification number to address the DCN. In the preferred embodiment, a single 
byte address is used to address a DCN on any given current loop. This one-byte 
address allows up to 256 DCNs to be supported on any given current loop 
network. In the preferred embodiment, only 64 such DCNs are connected to a 
single current loop network and therefore the single byte address is more than 
adequate. The single byte address substantially reduces the amount of traffic on 
the current loop network by reducing the number of bytes from four in the unique 
identification number to one for the shorthand token representation. 

The floor controller is responsible for generating the unique single byte 
address for each data communication node on a given current loop network. The 
process 508 of assigning unique addresses to the DCNs on the current loop 
network is shown in FIG. 31. The process begins by defining a range of unique 
identification numbers in step 512. Initially this will be a large range. 

Next, the floor controller sends out a message to all of the DCNs on the 
current loop network in step 514. The floor controller communicates with the 
DCNs by using a standard communication protocol. In the preferred 
embodiment, this protocol defines a message format including a destination ID, a 
source ID, a message length, a data packet and a CRC. Other message formats 
could be used as well. Using this format, the floor controller can communicate 
with all of the DCNs on the current loop network by using a global destination 
address in the message. This global destination address would indicate to the 
DCNs that this message is intended for all DCNs on the current loop network. 
This global message would include two unique identification numbers that, taken 
together, define the range of unique identification numbers established in step 



The individual DCNs then checks to see whether their unique identification 
number falls within this range. If a DCN's unique identification number falls 
within this range and the DCN does not have an address assigned thereto, the 
DCN then responds to this global message by sending a reply message in 
response that includes the unique identification number of that DCN. In the event 
that more than one DCN has a unique identification number that falls within this 
range a network collision will occur and the message will be corrupted. The 
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process 508 checks for this condition in step 516. This condition is indicated by 
an invalid CRC in the message. 

In the event of a network collision, the floor controller can limit the range 
of unique identification numbers by repeating step 512 in the hope of eliminating 
this network contention. 

If the response has a valid CRC, the floor controller assigns a unique 
address to the responding DCN, as identified by the unique identification number 
in the response, in step 518. The floor controller then transmits this address along 
with the corresponding unique identification number in an assignment message to 
all of the DCNs using a global destination address in step 520. The DCNs then 
process this message and in the event that the unique identification number 
included in the message corresponds to the DCN's unique identification number, 
the DCN adopts the address included in the message. Once the DCN has been 
assigned an address in this manner, the DCN will interpret all subsequent 
messages having a destination address equal to the assigned DCN address as 
being directed to that DCN. The above-described address assignment sequence is 
repeated for each of the remaining DCNs on the current loop network in step 522. 
The floor controller continues this process until the entire range of unique 
identification numbers has been covered and no more network collisions occur. 

4. System Monitoring 

Referring now to FIG. 32, the system monitoring step 474 will now be 
described. The floor controller is now responsible for monitoring certain system- 
wide conditions to determine whether certain events need to occur. The system 
monitoring step also handles request for particular machine information. Thus, in 
step 524, the floor controller determines whether a new request has been placed in 
the data base for such particular machine information. If such a request has been 
placed, the floor controller responds to the special request for data in step 526 by 
sending a message to the particular machine requesting the required information. 
Once the required information has been received, the floor controller processes 
this information accordingly. 

The floor controller also monitors the locally-stored meter information in 
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step 528. If the locally-stored information is changed, the floor controller saves 
the latest information to the data base in step 530. As described above, the floor 
controller saves the meter information locally in order to minimize the traffic to 
the file server over the high speed network. 

The floor controller also monitors the system for certain event triggers in 
step 532. These triggers can be stored in the data base and fetched by the floor 
controller during its power-up procedures. These triggers indicate if and when 
certain events occur. Examples of event triggers include: the drop period, the 
end-of-day, the bonus period, etc. If an event trigger has occurred, the floor 
controller handles the event in step 534. 

The handle event step 534 is shown in more detail in FIG. 33. The events 
can basically be bifurcated into accounting events and bonusing events. 
Accounting events refer to the data communication activity of the system. The 
accounting events are typically triggered by a certain time of day such as the end 
of day or the drop period. If an accounting event has been triggered, the floor 
controller performs the required data base operations in step 538. This step 
involves updating all of the locally-stored meter information and storing the 
updated meter information into the data base. 

The other type of event can be referred to as a bonusing event. The floor 
controller checks to see whether the; event is a bonusing event in step 540. The 
bonusing events can also be triggered by the time of day. For example, the 
bonusing event may be triggered from midnight to 4:00 a.m. on weekdays. These 
bonusing periods can be specified in the data base. If the triggered event is a 
bonusing event, the floor controller inserts a corresponding reconfiguration 
message in the output message queue in step 542. The reconfiguration message 
includes a reconfiguration command that is sent to an appropriate machine. The 
machine, upon receiving the reconfiguration command, reconfigures its payout 
schedule in accordance with the received reconfiguration command. According 
to the invention, there are many different reconfiguration commands to implement 
a multiplicity of different bonusing events. One reconfiguration command 
specifies that the machine should reconfigure its payout schedule to be a multiple 
of its default payout schedule. This reconfiguration command can also specify 
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that the multiple payout schedule should be limited to a predetermined percentage 
of the coins in. This reconfiguration command can further specify that the 
multiple payout schedule should be limited to only when the maximum coins are 
played. This reconfiguration command can further specify that the multiple 
payout schedule should be limited to payouts in a specified range. This 
reconfiguration command can also specify the multiple payout schedule should 
payout only when a predetermined level of player activity is reached. 

Another reconfiguration command allows any number of machines on the 
network to be combined in a common jackpot having a common jackpot payout 
schedule, wherein the reconfiguration command reconfigures the selected 
machines to payout in accordance with the common jackpot payout schedule. In 
this case, the reconfiguration message would be queued up for each of the 
selected machines to be combined in a common jackpot. One example of a 
common jackpot is a progressive jackpot. Unlike the prior art progressive jackpot 
systems, however, the progressive jackpot according to the invention is not 
limited to a predetermined number of machines. In the prior art progressive 
jackpot systems, a bank of machines are connected to a common progressive 
jackpot controller and only those machines can be included in the progressive 
jackpot. In contrast, any machine on the network, including those connected to 
other floor controllers can be combined into a common progressive jackpot. 
Moreover, the number of progressive jackpots is not limited by the number of 
floor controllers since one floor controller can manage more than one progressive 
jackpot. 

Another reconfiguration command permits the system to implement so- 
called "automatic mystery jackpots." These "mystery" jackpots allow a machine 
to payout a mystery jackpot even when a jackpot was not won. Instead, the 
reconfiguration command can specify that the mystery jackpot is to occur after a 
certain number of coins, a certain number of handle pulls, or a variety of other 
conditions specified by the reconfiguration commands. These mystery bonuses 
provide the casino with another way to induce additional gaming activity. 
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5. Bonus Control 

Referring now to FIG, 34, a method 550 for controlling the conditions 
under which the above-described bonus activities are activated is shown. It is 
essential for the system to have complete control over the amount and conditions 
under which a bonus is paid out in order to insure the profitability of the bonusing 
system. The method 550 described below provides the required control. 

The method 550 begins in step 552 by disabling or turning off the bonuses 
in the individual machines. This is accomplished by sending a message to the 
individual DCNs to turn off or deactivate bonusing. Next, the floor controller 
monitors the activities of the individual machines connected thereto. This step 
includes monitoring the coins in and bonuses paid for the individual machines, as 
described above. In step 556, the floor controller modifies a bonus pool by a 
predetermined percentage of all coins played. The bonus pool is essentially a 
pool of monetary resources that can be allocated for bonus awards. In the 
preferred embodiment, a predetermined percentage of the monetary value of the 
coins played are added to the bonus pool. Also in this step, any bonuses paid by 
the gaming devices are also measured and subtracted from the bonus pool. The 
use of the bonus pool will become more apparent when the other steps are 
described hereinbelow. 

In step 558, the floor controller determines whether or not bonusing is 
active. If bonusing is active, the floor controller next determines whether the 
bonus pool amount has dropped below a predetermined minimum level called the 
"turn-off level in 560. This minimum amount or floor can be set by the casino 
and provides, a buffer to account for large bonus awards and/or multiple bonus 
awards that could cause the bonus payout to exceed the bonus pool. Therefore, if 
the bonus pool drops below the turn-off level, the method 550 branches back to 
step 552 and turns off bonusing. As will described further below, the bonusing 
remains off until such time as the bonus pool builds up past another minimum 
level called the "turn-on" level. 

Returning to step 558, if the bonus is currently not active, the floor 
controller determines at step 562 whether the bonus pool has reached a 
predetermined turn-on level. This turn-on level can also be set by the casino and 




provides a buffer above the turn-off level to insure that the bonusing does not 
behave erratically, i.e., bonusing rapidly switching between on and off. If the 
bonus pool is not above the turn-on level, bonusing is again turned off in step 552. 

If the bonus pool has reached the turn-on level, the floor controller checks 
to see whether other bonus conditions are met at step 564. These bonus 
conditions can include, but are not limited to, a minimum period of time since the 
last bonus activation, a minimum level of play in the time period prior to the 
bonus pool reaching the turn on level, a predetermined time of day, or other 
predetermined conditions. These conditions give the casino additional control 
over the bonusing promotions. If the conditions are not met, the method 550 
branches back to step 552 where the bonusing is again turned off. If, however, 
the conditions are met in step 564, the bonus is turned on at step 566 and the 
method 550 branches to step 554 where the machine activity is again monitored. 

In the preferred embodiment, the method 550 is embodied in software that 
is executed by each of the floor controllers in the system. These floor controllers 
are then responsible for activating or deactivating the bonusing for the individual 
machines connected thereto. The system allows the floor controller to have 
multiple bonus pools and to have certain of the machines associated with a given 
bonus pool. Thus, the 

floor controller can implement multiple bonusing promotions simultaneously. 

This system also allows for machines connected to different floor 
controllers to be combined into a single bonusing promotion. In this case, one of 
the floor controllers assumes primary responsibility for managing the bonus pool 
while the other floor controllers act as intermediaries between the primary floor 
controller and the machines connected to the other floor controllers. Thus, the 
system according to the invention allows for much greater flexibility in running 
bonusing promotionals than heretofore possible. Prior art systems required 
certain predetermined machines to be connected into a bank for any given bonus 
award such as a progressive bonus. The system according to the invention allows 
any machine in the casino to be combined in a bonus type situation. The system 
also insures that the bonusing promotionals will operate substantially in the black, 
i.e., the bonus pool is greater than the bonus payouts. 
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D. PROMOTIONAL INCENTIVES 

To facilitate a description of the manner in which the promotional 
incentives of the present invention are implemented on the slot machine network 
described above, description will first be made of the manner in which the 
promotional incentives function from the perspective of the player, then the 
manner in which the casino operator implements and controls the incentive, and 
finally a description of the system operation and the types of reports relating to 
promotional incentive activity which can be generated. As will be seen in the 
following description, two types of promotional incentives are implemented in the 
present invention, namely a complementary incentive in which a player of slot 
machines is provided with (a) complementary credits which enable him or her to 
play the slot machine and collect any jackpots or (b) matching credits which 
encourage play by crediting the slot machine with a matching amount each time 
the player-deposits one of his or her coins. In both types of incentives, the player 
cannot cash out the promotional credits issued by the casino. 

1. Use by Player 



This incentive is typically provided to preselected customers when they 
first enter the casino. The player is issued a card, like card 120 in FIGs. 7A-7C, 
which is readable by card reader 100 associated with each of the machines in the 
casino. In a manner which will be more fully described, the casino associates a 
unique player identification number coded into the card 120 with a corresponding 
player account file maintained by file server 32. The account file includes the 
player's name, the amount of credit issued and other information to be described. 

To apply credit in the player* s account to one of the slot machines, the 
player inserts his or her card into one of card readers 100 associated with each slot 
machine. Two things occur responsive to insertion of the card. First, the amount 
of the credit balance remaining in the player's account appears on display 102 of 
the slot machine where the card was inserted. Second, the maximum number of 
coins playable on the slot machine selected by the player is debited from the 
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player's account and applied to the coin-in meter on the machine. Depending 
upon the slot machine configuration, the reels either spin automatically once the 
credits appear on the coin-in meter or the customer presses a button or pulls a 
handle to cause the reels to spin. 

If the particular combination appearing after the reels come to a halt is one 
for which a jackpot is paid to the player, the slot machine pays the jackpot in the 
usual fashion. This can include applying the amount to a credit meter which is 
included as a conventional item on many slot machines, paying the jackpot in 
"coins or tokens from the slot machine to the player, or, in the case of jackpots 
above a predetermined level, the casino may elect to hand pay the jackpot to the 
player. 

Immediately after each reel spin, an amount equal to the maximum number 
of coins playable on the selected slot machine is debited from the player's account 
and applied to the coin-in meter of the machine. If the player wishes to take a 
break or move to a different machine, the player must remove the card after the 
credit has been applied for the next spin of the reels but before the reels spin. The 
player can then switch to a different slot machine or suspend slot machine play 
until a later time. The card can then again be inserted into the slot reader 
associated with the machine and play resumes as described above. The player can 
continue to play until the credits in the player's account are depleted, or, as will 
later be described in more detail, a preselected amount of time passes after which 
the promotional incentive is no longer in effect. 

(b) Matching Incentive 
In the case of the matching incentive, the player is issued a card, usually on 
first entering the casino, in the same manner as described above. When the player 
inserts the card into a card reader, like card reader 100, associated with a slot 
machine, display 102 on the slot machine displays the remaining amount of 
matching credit in the player's account. Unlike the complementary incentive, no 
credit is applied to the player's account until he or she deposits a coin or token 
into the slot machine. Each time a coin is deposited, a credit in an amount 
matching the denomination of the coin is applied to the coin-in meter of the 





machine. It is to be appreciated that the credit can be less than or greater than a 
matching credit, but in the present embodiment of the invention it is credit which 
equals or matches each coin played by the player. 

In some cases a player may wish to play the maximum amount of coins on 
a slot machine upon which the maximum number of coins playable is an odd 
number. For example, in the case of a three coin maximum, the first coin 
deposited by the player is matched by a credit from the player* s account, thus 
providing two coins on the coin-in meter of the machine. When the player drops 
a second coin into the machine, the coin-in meter goes to the maximum number of 
coins playable, i.e., three coins, and the matching credit is applied to the slot 
machine credit meter which is a conventional component of most slot machines. 
The machine is then ready to activated with the maximum number of coins. For 
the next reel spin, the player can provide any credits from the credit meter to the 
coin-in meter and, if desired, play additional coins, which are matched as 
described above. The current credit balance in the player's account continues to 
be displayed on display 102. 

The player can remove the card from the card reader for play at a later time 
or at a different machine utilizing that machine* s associated card reader. As with 
the complementary incentive, there may be a predetermined time period during 
which the matching incentive is effective, matching not occurring either before or 
after the preselected time period. In addition, unlike the complementary 
incentive, the user may be automatically awarded additional matching credits by 
the system each time he or she plays a predetermined amount of money on a slot 
machines. 

2. Use by Casino Operator 

a. Complementary Incentive 

The present embodiment of the invention implements the promotional 
incentives only after each player has been entered in the player tracking system as 
described above. That is, each player has already been issued a player tracking 
card bearing a unique identification number and has established a corresponding 
player tracking account in a file on the central computer. 




Accordingly, after such a player tracking account is established by a casino 
employee, the system is in condition for establishing a credit to implement the 
complementary incentive for the player. The present embodiment of the 
invention is implemented on file server 32 which is controlled by a DOS 
operating system. The system supports a Paradox database, which includes 
screen displays described below, to facilitate entry by a casino employee to 
establish and/or modify a player account. A first screen includes the headings and 
fields depicted in the following Table 5. 



TABLE 5 - Complementary Incentive Entry Form 

1 . Player Account Number: ■ 

2. Time Restrictions 

Start Time:. 

End Time: 

3. Date Restrictions: 

Start Date: 

End Date: 

4. Initial Complementary Incentive Amount: $_ 



"In one~embodiment, file server 32 includes a card reader, like card reader 



100, connected directly to the computer. In such a case, the employee enters the 
player account number in the field above by inserting the card in the reader. So 
doing causes the player account number to appear in the field above. 
Alternatively, the player account number can be entered manually from the 
keyboard by the casino employee. The time and date restrictions clearly establish 
a starting date and time and an ending date and time during which the incentive is 
in effect. In other words, insertion of the card in the card reader prior to or after 
the established period will not provide any complementary credits to the slot 
machine coin-in meter. Finally, the casino employee fills in a preselected dollar 
amount to establish the amount of credit available to the player. 

Another screen associated with the Paradox database program permits the 
casino to adjust a player's complementary incentive account and includes the 
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headings and fields depicted in Table 6. 
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TABLE 6 - Complementary Incentive Adjustment Form 

1 . Player Account Number: K 

2. Adjustment amount: 

3. Current Free Play Value: $ 

4. Last Machine Played: 

5. Time Restrictions 

t Start Time: 

End Time: 



•\0 



10 6. . Date Restrictions 

Start Date: 



0* 



End Date: 



The current free play value and last machine played fields are not fields in 
which data can be entered but rather display the identified information. A 
"lis negative or positive number, however, can be entered in the adjustment amount 

EI % field to increase or decrease the complementary incentive available to the player. 

Similarly, the time and date restrictions can be altered to change the time period 



during which the incentive is in effect. 

a- 

b. Matching Incentive 
20 The match play incentive similarly utilizes a pre-existing player tracking 

account and optionally, a card reader associated with the file server to establish a 
matching incentive. An entry screen, also associated with the Paradox database, 
includes the headings and fields depicted in Table 7 below: 



TABLE 7 -Matching Incentive Entry Form 

25 1 . Player Account Number: 

2. Time Restrictions 



Start Time:. 



End Time 
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3. Date Restrictions: 

Start Date: 

End Date: 

4. Initial Match Play Amount: $; 

5. Award $ Matching Incentive for Every $ Played 



The matching incentive account can be established in one of three possible 
variations. First, there can be an initial match play amount and no additional 
award regardless of the amount played by the player. In such a case, the "award 

$ match play for every $ played" fields are left blank. Secondly, 

the initial match play amount can be left blank or set at zero with the fields in the 
last line being filled in to award a preselected amount of match play credits each 
time the player plays a predetermined amount of money. Thus, each time the 
player plays the predetermined amount of money, the predetermined match play 
credit is awarded to his or her account. It is used up as the player plays, as 
described above, until the player again plays the predetermined amount at which 
point the account is replenished with the amount of the award established in the 
entry form of table 7. The third way in which the account can be established is to 
provide both an initial amount of play, so that matching incentives begin as soon 
as the player begins playing, and to provide an additional credit award for every 
predetermined number of dollars played. 

As is the case with the complementary incentive, the matching incentive 
can be adjusted using a screen having the headings and fields set forth in the 
following Table 8. 



TABLE 8 - Match Play Adjustment Form 
1 . Player Account Number: 



3 



2. Amount to Adjust Current Match Play: 

3. Current Match Play Value: $ 

4. Award $ for Every $ Played 

5. Time Restrictions 
Start Time: 
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End Time: 

6. Date Restrictions 

Start Date: 

End Date: 



As is the case with the complementary incentive, the current match play 
credit can be adjusted upwardly or downwardly by entering a positive or negative 
number in the adjustment field shown in Table 8. Similarly, the amount of credits 
awarded for every predetermined number of dollars played can be adjusted using 
the appropriate fields in Table 8. The time during which the incentive is in effect 
can also be changed by entering new data in the time and date restrictions field. 

3. System Operation 

Because the manner in which system 10 effects operation of both the 
matching and complementary incentives is very similar, separate system 
operation descriptions are not necessary. In the following description, 
communication between player tracking module 44, data communication node 42, 
floor controller 1 8 and file server 32 occur as described above. 

When a player's card 120 is inserted into card reader 100, the identification 
number is provided from the card reader 100 in player tracking module 44 to the 
data communications node 42. Floor controller 18 receives the identification 
number from the data communications node and accesses the customer's file on 
the file server. The floor controller collects information from the player's file, 
including whether or not the player is eligible for either complementary or 
matching incentives, any credit balance remaining and the date and time 
restrictions. 

In the case of complementary incentives, if all the criteria are met, i.e., the 
player is within the time period during which the incentive is effective and credit 
remains in the account, the floor controller, which is programmed to assess 
whether or not the player meets the criteria, provides a credit message to DCN 42 
which in turn applies maximum credits to the coin-in meter of the gaming 
machine via personality board 202. The player then plays the game with any 
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jackpot being awarded by the slot machine in the usual fashion. All player 
transactions are logged in the usual fashion, including player identification 
number, machine number, amount played, amount credited by the complementary 
incentive, etc. Upon removal of the card, the credit balance remaining in the 
player's account is written to the player's log file in floor controller 18. 

In the case of a matching incentive player, when the floor controller 
accesses the file server for player information responsive to the player 
identification number, it also determines that the player is a matching incentive 
player. The floor controller determines whether there is a matching incentive 
credit available and whether it is within the effective predetermined time period. 
Each time the player plays a coin in the machine, this is communicated to data 
communication node 42 via personality board 202 which in turn provides this data 
to the floor controller. The floor controller provides a matching credit message to 
node 42 and logs the transaction, including player identification number, machine 
number, amount played, and amount matched. This information is provided to 
the player's account file in the file server. 

Upon card removal, the floor controller updates the player account file to 
reflect the amount of matching play credit remaining to the player. 

The floor controller uses the player tracking file, which includes all coins 
played by each player, to obtain the total of coins played to award additional . 
matching incentive credits pursuant to the criteria set when the player's matching 
incentive account was established. 

In either complementary or matching incentive credit accounts, multiple 
cards may be issued for a single account (i.e., cards having the same identification 
number), for example, one card each to a couple. In such a case, only the first to 
insert the card can access the account; if a second card having the same 
identification number is inserted after the first card, the second card does not 
permit access to either the matching or complementary incentive credit. 

If the time period should end while a card is inserted, the player can 
continue to play, assuming credits remain for either of the incentive types, for so 
long as the card remains inserted. Upon removal of the card after the end of the 
time period, the incentive is no longer enabled responsive to card insertion. 
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4. Reports 

Because each transaction in both incentives is logged, i.e., the amount 
played by the customer, the amount of credit used from the incentive account, the 
machine upon which the transaction occurred, the name of the casino agent who 
effected any changes to the player incentive account, the time of the play or other 
event, etc., numerous reports can be assembled by the Paradox database to 
indicate activity on the part of a selected player or casino agent or to summarize 
such activity. Similarly, activity information can be analyzed by machine 
including the amount of incentive redeemed, and in the case of matching 
incentive, the amount of incentive awarded (based on play by the player) at a 
particular machine. 

It can thus be seen that the matching and complementary incentives 
implemented by the present invention provide a casino operator with a tool which 
motivates players to play the machines by providing complementary or matching 
credits while at the same time preventing the credits from being cashed out and 
used by the players for other purposes. In addition, the present system maintains 
detailed records of all transactions on the part of players and casino employees 
and provides reports detailing and summarizing these transactions. 

Having described and illustrated the principles of the invention in a 
preferred embodiment thereof, it should be apparent that the invention can be 
modified in arrangement and detail without departing from such principles. For 
example, although an Ethernet network was described in the preferred 
embodiment of the invention, other high-speed networks such as wireless 
networks could be used in place thereof. I claim all modifications and variation 
coming within the spirit and scope of the following claims. 




